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(57) Abstract 

The invention relates to various methods for configuring configurable hardware blocks. The methods are especially characterized by 
generation of the configuration data used to configure the hardware blocks. The methods described for generating configuration data enable 
configuration data to l)e generated and allow hardware blocks to be configured easily, quickly and efficiently using said configuration data. 



(57) Zusammenfassung 

Es wenlen vcrechiedene Verfahren zur Konfiguriening von konfigurierbaren Hardware-BIocken beschrieben. Die Verfahren zeidinen 
sich insbesonderc durch die Generierung der Konfigurationsdaten aus. unier Verwendung . wclchcr die Hardware-Blocke konfiguncri 
werdcn. Durch die beschriebcnc Konfigurationsdaten-Erzeugung konnen sowohl die Konfigurationsdaten-Erzeugung selbsl als auch die 
Miirdwiire-Block-Konfiguriening unier Verwendung dieijer Konfigurationsdaten einfach, schncll und effizient durchgefuhrt wer^^ 
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Beschreibung 

Verfahren zum Konf Igurieren eines. konfigurierbaren Hardware^ 
Brocks • • ' 

Die vorliegende Erfindung betrifft ein Verfahren gemaJi dem . 
Oberbegriff der Patentansprtiche 1 und 22, d.h. ein Verfahren 
zum Konf igurieren eines konf igurierbaren Hardware-Blocks. 

Ein derartiges Verfahren wird unter anderem beriotigt, tun die 
sogenannte s-unit eines sogenannten >S<puters zu konf igurie- 
ren. Ein >S<puter ist ^ine programmgesteuerte Einheit, die 
insbesondere durch die Verwendung eines konf igurierbaren 
Hardware-Blocks in dem die Befehle abarbeitenderi Teil in der 
Lage ist, mehr als einen Befehl pro Prozessortakt auszufiih- 
ren. 

Ein .solcher >S<puter ist beispielsweise aus der EP 0 825 540 
Al bekannt. 

Der grundlegende Aufbau eines >S<puters ist in Figur. 11 ge- 
zeigt und wird nachfolgend unter Be zugnahme hierauf beschrie 
ben. 

Der Vollstandigkeit halber. sei bereits ah dieser Stelle dar- 
auf hingewiesen, dafi. der >S<puter, insbesondere dessen die 
Befehle abarbeitende Teil nur. teilweise (nur so weit es ftir 
die vorliegend naher betrachteten konf igurierbaren Hardware- 
Blocke und deren Konf igurierung von Bedeutung ist) dar- 
gestellt und beschrieben ist. 

Der >S<puter gemaii Figur 11 umfaSt eine Vordecodier-Einheit 
(predecode unit) 1, einen Instrukt ions-Puffer (instruction. 

buffer) 2, eine Decodier-, Umbenennungs- und Lade-Einheit 
(decode, rename & load unit) 3, die bereits erwahnte s-Para- 

digmen-Einheit (s-unit) 4, einen Daten-Cache (data cache) 5, 

und eine Speicher-Schnittstelle (memory interface) 6, wobei 
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die s-unit 4 aus einem Strukturprograinmier-Puf f er (programma- 
ble structure buffer) 41, einer Funktionseihheit mit pro- 
grammierbarer Struktur (functional unit with programmable 
structure) . 42, einem Integer/AdreBinstruktions-Puf f er 
5 (integer/address instruction buf f er) 43. imd einem Register- 
. block, (integer .register file) 44 besteht^ 

Die Besonderheit des >S<puters besteht insbesondere in dessen 
s-unit 4, genauer gesagt in der functional unit 42 derselben.; 
10 Die functional unit 42 ist eine kpnf igurierbare Hardware, die 
basierend auf vom >S<puter auszuf tihrenden Befehlen oder 
Befehlsfolgen dynamisch so konf igurierbar' ist, dafi sie die 
durch die Befehle oder Befehlsfolgen vorgegebenen Aktionen 
bzw. Operationen ausfiihren kann* 

15 

Vom >S<puter auszuf ilhrende Instruktionen (genauer gesagt 
diese reprasentierende Code-Daten) gelangen aus einem nicht 
gezeigt^h Speicher iiber das memory interface 6 in die pre- 
decode unit 1, wo. sie vordecodiert werden; dabei kOnnen zu 

20 den Code-Daten beispielsweise Informationen hinzugefUgt wer- 
den, die die spatere Decodierung in der decode, rename & load 
unit 3 erleichtern. Die Code-Daten gelangen dann tiber den' 
instruction buffer 2 in die decode, rename & load unit 3, wo 
die Ausf iihrung der duirch die Code-Daten reprSsentierten 

25. Befehle vorbereitet wird. Diese Vdrbereitung umfafit die 

Decodierung der Code-Daten, die . Konf igurierung bzw. Struktu- 
rierung der functional, unit 42, die Initialisierung bzw. 
Verwaltung des integer register file 44, und das Starten der 
wunschgemafi konf igurierten functional unit 42. 

.30 

Die Strukturierung bzw* Konf igurierxing der functional unit 42 
erfolgt uiiter Verwendung von die gewtinschte .Konf iguration 
represent ierenden Konf igurations-Daten, die von der decode, 
rename & load unit 3 in den programmable structure buffer 41 
35 geschrieben werden. Diese, die gewtinschte Konf iguration re- 
prasentierenden Konf igurations-Daten werden in der decode. 
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rename & load iinit 3 kreiert; sie konnen aber auch schon in 
codierter iTonn in deri Code-Daten enthalten sein.. 

Die functional unit 42 ist dazu ausgelegt^ Daten ails deii 
5 register file 44 und/oder dem data cache 5 auszuleseri/ die., 
ausgjelesenen Daten arithmetisch und/oder logisch zu verarbei- 
ten, vmd das Ergebnis der Verarbeitung reprasentierende Daten 
in das register file 44 und/oder den data cache 5 einzu-- 
schreiben. 

io 

Bei geeigneter Ini tialisierung des register file 44 und bei 
geeigneter Konf igurierung der . functional unit 42 hat der Be- 
trieb der functional unit 42 die Ausfuhrung der Operationen 
zu Folge, die durch die Ausfuhrung der Befehle, auf der Basis 
15. welcher die Initialisierung des register file 44 und die Kon- 
figurierung der functional unit 42 erfolgten, zu bewirken 
sind. 

Die Vornahme der durch die AusfOhrung von Instruktionen zu 
20 bewirkenden Aktionen durch eine entsprechend. konf igurierte 
Hardware, (die functional unit 42) ist bekanntlich bedeutend 
.schneller als die Ausftihrung der Befehle in den "normalen" 
Arithmetisch/Logischen Einheiten (ALUs) von herkommlichen . 
programmgesteiierten Einheiten.. Dies grilt in bespnderem Mafie. 
25 ftir den Fall, dafi die Hardware (die functional unit 42!) so 
konf iguriert ist,.. daB durch deren Betrieb ein Ergebnis er- 
zielbar ist, das der Ausftihrung mehrerer auf einanderfol.gender 
Befehle (eines mehrere Befehle umfassenden Makrobef ehls) ent- 
spricht . 

• .30- 

Bezuglich weiterer Einzelheiten zum Aufbau, der Funktion und 
der Wirkungsweise von >S<putern und der darin. enthaltenen. 
konf igurierbaren Hardware wird auf die vorstehend bereits 
erwahnte EP 0 825, 540 Al verwiesen. 

35 

Der Vollstandigkeit halber sei angemerkt, dafi nicht alle 
Aktionen, die durch die vom >S<puter auszuftihrenden Befehle 
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zu bewirken sind, durch die functional unit 42 ausfuhrbar 
sind, Befehle wie insbeisbndere zur Programmablauf steuerung 
bzw. Kontrollflufisteuerung dienende Befehle wie beispiels- 
weise Branch-/ Jump-, No-Operation-, Wait- uhd Stbp-Befehle 
5 werden in der Kegel auf herkbininliche Art und Weise ausgefiihrt 
werdenlv . .. 

Nichtsdestotrotz kann durch die Verwendung konf igurierbarer 
Hardware-Blocke wie der functional unit 42 im allgemeinen 

10 eine. hohere . Anzahl von durch auszuf uhrende Befehle zu. bewir- 
^ kenden Aktionen pro Zeiteinheit ausgefiihrt . werden als es mit 
herkommlichen programmgesteuerten Einheiten der Fall ist, - 
also mehr als ein. Befehl pro Prozessortakt abgearbeitet. wer- , 
den. 

15 ■ : ■ ■ . 

Voraussetzung ist natiirlich, daJi die Hardware-Blocke schnell 
konfiguriert und effizient genutzt werden. 

Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde, 
20 das Verfahren gemaB. dem Oberbegriff des Patentanspruchs 1 

derart weiterzubilden, dafi die Hardware-Blocke fur beliebige 
, Anwendungen schnell. und einfach konf iguri e.r bar und ef fizient 

nutzbar sind. 

25 biese. Auf gabe wird erfindungsgemaB durch die im kennzeichnen- 
den Teil des Patentanspruchs 1 und durch die im kennzeichnen- 
den Teil des Patentanspruchs 22 beanspruchten Merkmale 
gelost. 

30 Deitinach ist vorgesehen, 

- daB die Hardware-Block-Konf igurierung unter Verwendung von 
Konf igurationsdaten erfolgt, die aus einer Umsetzung von 
Befehlen Oder Biefehlsfolgen eines auszuftihrenden Programmes 
35 resultieren, und dafi bei der Umsetzung der Befehle oder 
Bef ehlsfolgen die Schritte . 
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- Ermittlung der zur Ausftihrung eines jeweiligen Befehis 
benOtigten Art yon Teileinheit des korif igurierbareii 
Hardware-Blocks/ 

- Auswahl einer noch nicht anderweitig belegten Teileiriheit 
5 der zuvor ermittelteri Art, und - sof ern eihe seiche Teil- 
einheit gefunden werden konnte - . . 

- Konf igurieren von um die ausgewahlte Teileinheit herum 
vorgesehenen konf igurierbaren Verbindungen 

ausgefuhrt werden (kennzeichnender Teil des Patentanspruchs 
10 1) bzw. 1 

- daB die Hardware-Block-Kpnf igurierung unter Verwendiing . von 
Konf igurationsdaten erfolgt, die aus einer Urns etzung des 
Codes resultieren, der generiert wird, wenn eine Schaltung, 
15 die durch den konf igurierbaren Hardware-Block realisiert 
werden soil, unter Verwendung einer Schaltungs- 
beschreibungssprache definiert wird (kennzeichnender Teil 
des Patentanspruchs 22) . . 

20 Durch eine derartige Vorgehensweise lassen sich zu konfigu- 
rierende Hardware-Blocke unter alien Umstanden mi t minimal em 
Aufwand wunschgemaB konf igurieren. Die Konf iguration erf olgt. 
dabei.sehr schnell und nutzt die Koiriponenten des Hardware- 
Blocks optimal aus; so konf igurierte Hardware-Blocke lassen 

25 sich sehr effizient einsetzen. . 

Vorteilhafte. Weiterbildungen der Erfindiing sind den Unter- 
ansprilchen, der nachfolgenden Beschreibung und den Figxiren 
ehtnehmbar . 

30 

Die Erfindung wird nachfolgend anhand von. Ausftihrxingsbeispie- 
len. unter Bezugnahme auf die Figuren naher erlautert. Es zei- 
gen 



35 Figuren lA bis ID ein Beispiel ftir einheitliche Befehls- 

Formate, die die umzusetzenden Befehle im betrach- 
teten Beispiel aufweisen sollten oder in die sie 
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vor Beginn der Umsetzung vorzugsweise gebracht 
warden, 

Figur 2 eine bei der hardwarem^iiigen Realisieruhg der^ '' 
5 setziing verwendete Lobk-Up-Table/ 

Figuren 3A und 3B das Format der aus der Look-Up-Table gemaB 
Figur 2 ausgegebenen Daten, 

-10 Figur 4 das Blockschaltbild einer Schaltung zur Aiiswahl 

und Konf igurierung einer zur Ausfuhrung eines Be- 
fehls benotigten Teileinheit des .Hardware-Blocks, 

Figur 5 das Blockschaltbild einer Schaltung zur Festlegung 
15 der Daten- und/oder Signalquellen und der Daten- 

und/oder Signalziele fiir die durch die Schaltung 
gemafi Figur 4 ausgewahlte Teileinheit, 

Figur 6 das Blockschaltbild einer Schaltung zur Handhabung 
20 von in den umzusetzenden Befehleri enthaltenen Kon- 

stanten/ 

Figur 7 das Blockschaltbild einer Schaltung zur DurchfUh- 
. rurig des sogjBnannten Da tai Forwarding, 

25 ' ' ■■ : ' ■ ■ ■ " ■■■ ■/ ■ ■ 

Figur iB einen sogenannten Cross-Bar-Switch zum Einschrei- 
ben der Konf igurations-Daten in einen temporaren 
Bitstrom, 

30 Figur 9 eine Anprdnung zum Einschleusen des temporaren 

Bitstroms in einen Hauptbitstrom, 

Figur 10 eine komplette Anordnung ziom Umsetzen von Befehlen 
in Konf igurations-Daten zur wunschgemaBen Konfigu- 
35.. rierung des Hardware-Blocks, 



Figur 11 



den prinzipiellen Aufbau eines >S<puters, und 
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Figur 12 den prinzipiellen Aufbau eines Hardware-Blocks der 
vorliegend naher betrachteten Art. 

5 Ziir Erleichterung des Verstandnisses wird zunSchst der. prih-- 
zipielle Aufbau eines Hardwarer^Blocks beschrieben,^ durch 
die danach beschriebene Verfahren konfiguriert werden soil. 

Der prinzipielle. Aufbau eines solchen Hardware-Blocks ist in 
10 Figur 12 gezeigt. Der gezeigte Hardware-Block, ist dazu aus- 
. gelegt ist, abhangig von seiner Konf igurierung in einer 
Speichereinrichtung gespeicherte Daten auszulesen, . die aus- 
gelesenen Daten arithmetisch \ind/oder logisch zu verarbeiten 
und das Ergebnis der Verarbeitung reprasentierende Daten in 
15 die Speichereinrichtung einzuschreiben; er ist beispielsweise 
als die functional unit 42 des >S<puters gemaB Figur 11 ein- 
setzbar. 

Die Speichereinrichtung, aus welcher der konf igurierbare 
20 Hardware-Block Daten ausliest und in welche der Hardware- 
Block Daten einschreibt, kann innerhalb oder aufierhalb des 
Hardware-Blocks vorgesehen sein; im vorliegend betrachteten. 
Beispiel wird die Speichereinrichtung durch das register file 
.44 des >S<puters .gemafi Figur 11 gebildet. Der Hardware-Block 
25 ist ein asynchrories Schaltnetz zwischen den Aus- und Eiiigkn- 
gen der Speichereinrichtung; die Bestandteile des Hardware- . 
Blocks sind asynchrdn miteinander gekoppelt. 

Die Speichereinrichtung. ist vorzugsweise von aufierhalb des 
30 Hardware-Blocks vor der Inbetriebnahme desselben initiali- 
sierbar; denkbar ware auch, daB der Hardware-Block die 
Initialisierung der Speichereinrichtung selbst veranlafit oder 
durchfUhrt. 

35 Def in . der Figur 12 gezeigte Hardware-Block weist. eine oder 
mehrere arithmetische Einheiten AUl, AU2/ eine oder mehrere 
Vergleichs-Einheiten CU, einen oder mehrere Multiplexer eines 
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ersten Typs MUXAl, MUXA2, MUXA3, einen oder mehrere Multi- 
pliexer eines zweiten Typs MUXB, und einen. oder mehrere De- 
multiplexer DEMUX auf . 

' 5 Die arithmetischen Einheiten AUl, AU2 weis^h im; betrachteteh 
Beispiel zwei Eingangsanschlusse, einen AusgangsanschluiJ und. 
einen SteueranschluB auf.. Den arithmetischen Einheiten AUl, 
AU2 obliegt es, die liber deren Eingangsanschliisse eingegebe- 
nen Eingangssignale arithmetisch und/oder logisch zu verar- 

10 beiten. Die pperationen, die durch die arithmetischen Ein- 
heiten AUl, AU2 ausftihrbar sind,. konnen fest vorgegeben oder 
individuell einstellbar (konf igurierbar ) sein; sie umfassen 
insbesondere arithinetische Operationen wie Addition, Subtrak- 
tion, Multiplikation, Division etc., logische Verkniipf ungen 

15 wie UND-Verkniipf ungen, ODER-Verkniipf ungen, Invertierung, 
Komplementbildung etc, , arithmetische und logische Shift- 
Operationen, lind Datentransf ers (Durchschaltung eines der 
eingegebenen Signale zum Ausgangsanschlufi) • Die arithmeti- 
schen Einheiten AUl, AU2 sind nicht mit den Arithmetisch/- 

20 Logischen Einheiten (ALUs) herkommlicher programmgesteuerter 
Einheiten wie Mikroprozessoren, Mikrocontrollern etc. gleich- 
zu?etzen; die von ihnen ausftihrbaren Operationen sind be- 
grenzt, so daB der Aufbau der arithmetischen Einheiten. AUl,. 
AU2 vergleichsweise. einfach bleiben kann. Ober die Steuer- 

25 anschltisse der arithmetischen Einheiten AUl; AU2 ist fest- 
legbar, ob die betreffende arithmetische Einheit die Opera- 
tion, zu deren Ausftihrung sie vorgesehen. ist, ausfuhrt oder 
hicht. Dies eriaoglicht die praktische Umsetzung von Befehlen, 
deren Ausftihrung vom Vorliegen einer bestimmten Bedingung ab- 

30 hangt. Die Bedingung kann beispielsweise der Zustand eines 
bestimmten Flags sein: ist das Flag gesetzt, wird die der 
betreffenden arithmetischen Einheit obliegende Aufgabe (bei- 
spielsweise eine Addition) ausgefUhrt, andernfalls nicht 
(oder umgekehrt) . Derartige, nachfolgend als "konditidnierte 

35 Befehle" bezeichnete Befehle errabglichen es,.die schwer hand- 
habbaren bedingten Sprungbef ehle zu .eliminieren; sie werden 
spater noch genauer beschrieben. 
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Die Vergleichs-Eiiiheit CU weist im betrachteten Beispiel zw.ei 
Eingangsanschlusse und einen. Ausgangsanschliiii auf . Der Ver- 
gleichs-Einheit CU obliegr es/ die an deren Eingangsanschlus- 
sen anliegehden Signale oder Daten Vergleichsoperationen zu 
unt^rziehen. Die Operationen, die durch die Vergleichs- . 
Einheit CU ausfuhrbar sind/ konnen fest vorgegeben oder 
individuell einstellbar (konf igurierbar ) sein; sie umfassen 
beispielsweise GroBer-, GroBer/Gleich-, Kleiner-, Kleiner/- 
Gleich-, Gleich-/ und Ungleich-Vergleiche und Uberprtif ungen 
auf wahr (TRUE) und unwahr (FALSE). Der AusgangsanschluB der 
Vergleichs-Einheit CU ist uber deh naehfolgend noch genauer 
beschriebenen Demultiplexer DEMUX mit. den Steueranschiussen 
der arithmetischen Einheiten AUl, AU2 verbunden. Vom Ergebnis 
der in der Vergleichs-Einheit CUausgefiihrten Operation hangt 
es also ab/ ob die arithmetischen Einheiten AUl, AU2 die 
Operation, zu deren Ausfuhrung sie. vorgesehen sind, ausfuhren 
Oder nicht . 

Die Multiplexer des ersten Typs MUXAl, MUXA2, MUXA3, der 
Multiplexer . des zweiteh Typs MUXB, und der Demultiplexer. 
DEMUX dierien . zur Auswahl . der Dateri- . und/oder Signalquellen.. 
und der Daten- und/oder Signalziele. Genauer gesagt dienen 

- der Multiplexer MUXAl zur Auswahl der Quelleii der den Ein- 
gangsanschlussen der arithmetischen Einheit . AUl zugefUhrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
quellen sind im betrachteten Beispiel das register file 44 
und andere arithmetische Einheiten) ; 

- der Multiplexer .MUXA2 zur Auswahl der Quellen der den 
Eingangsanschliiissen der arithmetischen EinJieit AU2 . zuge- 
ftihrten Daten und/oder Signale (mogliche Daten- und/oder 
Signalquellen sind im betrachteten Beispiel das register 
file 44 und andere arithmetische Einheiten) , 
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- der Multiplexer MUXA3 zur Auswahl der Quellen der den 
Eingangsanschltissen der Vergleichs-Einheit CU zugefiihrten 
Daten und/oder Signale (mogliche Daten- und/oder Signal- 
quellen sirid im betrachteten Beispiel das register file 44 
und die-'arithmetischeh . Ein^^ , 

- der Multiplexer MUXB zur Auswahl der Quellen der deiti 
register file zugefuhrteh Daten und/oder Signale (mogliche 
Daten- und/oder Signalquellen sind im betrachteten Beispiel 
die arithmetischen Einheiten und/oder das register file 
selbst) , 

- der Demultiplexer DEMUX zur Auswahl des dder der Ziele. fur :. 
die von der Vergleichs-Einheit CU ausgegebenen Daten 
und/oder Signale (mogliche Daten- und/oder Signalziele sind 
im. betrachteten Beispiel die arithmetischen Einheiten). 

Die Multiplexer des ersten Typs weisen mehrere Eingangs- 
anschlusse und zwei Ausgangsanschliisse auf, die Multiplexer 
des zweiten Typs mehrere Eingangsanschlusse und einen Aus- 
gangsanschluii/ .und der Demultiplexer einen EingangsanschluB 
und mehrere Ausg;angsanschltisse. 

Die Multiplexer und der Demultiplexer weisen xn der Figur 12 
nicht gezeigte SteueranschlUsse auf, iiber welche einstellbar 

. 1st, welche Eingangsdaten und/oder -signale auf welche Aus- 
gangsanschliisse durchgeschaltet werden. Die Anzahl der 
SteueranschlUsse hangt yon der erf orderlichen Anzahl der 
verschiedenen Zuordnungs-Kombinationen ab; b6i 32 Eingangs- 
anschltissen und zwei AusgangsanschiUssen sind beispielsweise 

. 10 Steueranschltisse erforderlich, um an beliebigen Eingangs- 
anschltissen anliegende Signale und/oder Daten auf beliebige 
Ausgangsanschliisse durchschalten zu konnen. Im. Fall des Ein- 
satzes des Hardware-Bloclcs als functional unit 42 im >S<puter 
gemaii Figur 11 sind die: Steuersignalanschltisse vorzugsweise 
mit dem programmable structure buffer 41 verbunden, so dafi 
die in diesen eirigeschriebenen Konf igurations-Daten im we- 
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sentlichen unmittelbar ziir Multiplexer-Ansteuerung verwendbar 
sind. Die im programmable structure buffer 41 gespeicherten 
Konfigurations-Daten lomfassen vorzugsweise auch die Konfigu- 
rations-bateri zur Festlegung der jeW der 
5 arithmetischen Einheiteii AUl.,^ AU2:' Uiid der \Vei:gleich^^ 
GU. i . , . ' . ■ . 

Durch die arithmetischen Einheiten AUl, AU2, die Vergleichs- 
Einheit CU, die Multiplexer des ersten Typs MUXAl, MUXA2, 

10 . MUXA3, den Multiplexer des zWeiten Typs MUXB,. und den De- 
multiplexer DEMUX wird der Hardware-Block in die Lage ver- 
• setzt, in einer Speichereinrichtung (im register file 44) . 
gespeicherte Daten auszulesen, die ausgelesenen Daten arith- 
metisch und/oder logisch zu verarbeiten und das Ergebnis der 

15 Verarbeitung reprasentierende Daten in die Speichereinrich- 
tung (das register file 44) einzus.chreiben. 

Der in Figur 12 gezeigte und unter Bezugnahme darauf 
beschriebene Hardware-Block ist nur zur Erlauterung . des 

20 grundlegenden Aufbaus gedacht. In der Praxis werden die . 
arithmetische Einheiten, die Vergleichs-Einheiten, die 
Multiplexer, und die Demultiplexer in einer deutlich g.roBeren 
Anzahl yorgesehen werden als es beim .Beispiel gemSB Figur 12 
. der Fall ist, Der Hardware-Block ist vorzugsweise so 

25 . dimehsioniert/ daB normalerweise sSmtliche bperatiOnen, die 
von einem. spater noch naher beschriebenen/ sogenannten 
Hyperblock zu bewirken sind, auf ein Mai in ihn 
einprogrammierbar sind.. 

30 Die im Hardware-Block vorgesehenen Daten-. und/oder Signal- 

pfade konnen durch einzelne Leitungen Oder durch Busse.gebil- 
det werden, wobei es sich als vorteilhaft erweisen kann, wenn 
in den einzelnen Teileinheiten des Hardware-Blocks oder im 
Bus-System konf igurierbar ist, wie viele und/oder weiche Bus- 

35 leitungen zu beriicksichtigen sind. 
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Die Konf igurierung eines Hardware-Blocks nach Art der. Figur 
12 kann basierend auf Befehlen oder Bef ehlsf olgen erfolgen. 
Setzt man Befehle oder Bef ehlsf olgen in entsprechende Hard- 
ware--Block-Strukturen um/ so ist der so konf igurierte Hard-- 
. 5 : .ware-Block als Ablauf einheit ftir sequentielle. Bef ehil.sf olgen . 
nutzbar . Diese Form der Hardware-Block-Konf igurierung wird . 
nachfolgend auch als struktur-prozedurale Programmierung 
bezeichnet . 

10 Ausgangspunkt fur die struktur-prozedurale Prograinmierung 

kann ein in einer Hochsprache wie beispielsweise C, C++ etc* 
. - ■ geschriebenes Programm sein* Dieses Programm wird durch . einen 
Compiler iibersetzt, und der dabei erhaltene Code wird 
(vorzugsweise hyperblock-weise) in Strukturinf ormationen 
15 umgesetzt, basierend auf welcher der zu konf igurierende Hard- 
ware-Block konfigurierbar ist. Was unter einem Hyperblock zu 
verstehen ist, wird spater noch genauer beschrieben werden. 

Ausgangspunkt ftir die struktur-prozedurale Programmierung 
20 kann selbstverstahdlich auch. ein in Assembler- geschriebenes. 
• Oder sohstiges Programm sein. Die Art und Weise der Pro- 
grammierung (funktional, imperativ, objekt-orie.ntiert, 
ist ebenfalls keinen Einschrankungen unterworf en. 

25 Es erweist sich als : vdrteilhaf t wenn der in die Struktur- 
inf ormation umzusetzende Code, also die durch den Compiler 
Oder auf andere Art und Weise erzeugten Maschinenbef ehle nur 
bestiimnte Maschinenbef ehl-Typen, namlich unkonditionierte Be- 
fehle, konditionierte Befehle,. Predicate-Be f ehle, und Loop- 

30 Befehle timfassen, Dann lassen sich . in der Kegel besonders 
lange (besonders viele Befehle enthaltende) Bef ehls-Blocke 
mi t nur einem Eintrittspunkt und hur einem Austrittspunkt 
bilden. Die Generierbarkeit von moglichst langen Befehls- . . ' 
Blocken mit nur einem Eintrittspunkt und nur einem Austritts- 

35 punkt ist sehr bedeutsam, well sich Befehle, die ein- und dem 
selben Bef ehls-Blbck angehoren, und zwar nur solche Befehle, 
als eine Einheit (als eine sich aus mehreren Befehlen zu- 
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sammensetzende Makroinstruktion) behandeln lasseri/ die in 
eine gemeinsame Hardware-Block-Struktur umgesetzt und auf ein 
Mai ausgeftihrt warden kann . Legt man der Konfigurieruhg eines 
. Hardware-Blocks jeweils geriau eihe sdlche Einheit 2 
5 (urid ist der Hardware-Block groB geiiug/ um so konfiguriert 
werden zu konnen) , so lafit sich die Anzahl der zur Abarbei- 
tung eines ProgramiQS erf orderlichen Umstrukturierungeri bzw. 
Umkonf igurierungen des Hardware-Blocks auf ein Minimum redu- 
zieren. Die Bef ehls-Blocke, deren Generierung derzeit favori- 
.10 siert wird, und deren Bildung durch die . vorstehend genannteh 
Befehlsgruppen auch moglich ist, sind die vorstehend bereits 
erwahnten Hyperblocke. 

Hyperblocke zeichnen sich insbesondere dadurch aus, daB be- 
15 dingte Sprungbef ehle unter Anwendung der nachfolgend noch 

naher beschriebenen sogenannten if-Konversion eliminiert wer- 
den. . 

Bezuglich weiterer Einzelheiten . zu den Hyperblocken, anderen 
20 Bef ehls-Blocken und damit in Zusammenhang stehenden Themen 
wird auf 

- Wen-Mei .W. Hwu et al. :. "Compiler Technology for Future 

: Microprocessors'^ > Invited Paper . in Proceedings of the IEEE, 
25 Vol / 83 (12) , Dezeinber 1995, Special Issue on Miciro- 
processors, Seiten 1625 bis 1640, 

- Henk Neefs, Jan van Campenhout: "A Microarchitecture for a 
Fixed Length Block Structured Instruction Set Architec- 

30 tiire". Proceedings of the Eighth IT^TED International. 
Conference on Parallel and Distributed Computing and 
Systems, Seiten 38 bis 42, lASTED/ACTA Press, 1996, und 

- Richard H. Littin, J, A, David McWha, Murray W. Pearson, 
35 John G. Cleary: "Block Based Execution and Task Level 

Parallelism", in: John Morris (Ed, )/ "Computer Architecture 
98", Proceedings of the S*"** Australasian Computer Architec- 
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ture Conference, ACAC'98, Perth, 2-3 February 1998, Austra- 
lian Computer Science Communications, Vol. .20, No. 4, Sei- 
ten 57 bis 66, Springer, Singapore, 



5 verwieseii.- ■ " ' ' • " . 

Die vorstehend erwahnten unkonditionierten Befehle sind Be- 
fehle zur bedingungslosen. Bearbeitung von Daten einschlieB- 
lich der Kopie von Daten von einem Speicherbereich in einen 

10 anderen (von einem Register in ein anderes) . Diese Befehle 

werden im folgenden als normale Befehle bezeichnet. Sie urn- . 
f assen - arithiiietische und. logische Verkniipf ungen zwischen 
Daten zu neuen Werten und die sogenannten Move-Bef ehie zur 
Kopie von Registerinhalten. Das allgemeine Format dieser Be- 

15 fehle lautet: <Mnemonic> <Ziel-Register>, <Quellen-Register 
1>/ <Quellen-Register 2>. Zur Durchftlhrung der durch einen 
solchen Befehl spezif izierten Operation wird normalerweise 
eine arithmetische Einheit des Hardware-Blocks benotigt. 

20 Die konditipnierten Befehle sind Befehle zur Bearbeitung von 
Daten bei Vorliegen einer bestiramten Bedingung. (Konditibn) . 
Die durch diese Befehle auszuftihrenden Aktionen entsprechen . 
den durch die normalen Befehle ausfiihrbaren Aktionen, wobei 
die AusfUhrung der betreffenden Aktionen jedoch von einer 

25 vorbestimmten Bedingung abhahgt . 1st die Bedingung. erf till t, 
wird die durch den Befehl spezif izierte Aktion ausgefOhrt, 
anderenfalls wird nichts ausgefiihrt (der betreffende Befehl 
wirkt dann wie ein; NOP-Bef ehl) . Diese Befehle werden im fol- 
genden als bedingte Befehle bezeichnet. Das allgemeine Format 

30 dieser Befehle lautet: <Mnemonic>p <Ziel-Register>, <Quellen- 
Register 1>, <Quellen-Register 2> <p-Flag>, wobei durch das . 
"p" am Ende des Mnemonic die Abhangigkeit der Bef ehlsausf uh- 
rung von einer Bedingung signalisiert wird, und wobei die 
Bedingung durch einen bestimmten Zustand eines bestimmten 

35 Flags (des "p-Flag") definiert wird. Zur DurchfUhrung der 
durch einen solchen Befehl spezif izierten Operation wird 
normalerweise eine arithmetische Einheit des Hardware-Blocks 



./ 
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benotigt; zur Oberprtifiing der Bedingung wird eine Vergleichs- 
Einheit benotigt, deren Ausgang mit dem Steuereingang der 
arithmetischen Einheit verbindbar ist. 

5 . Die Predicate^Bef ehle sind Befehle ziir Festlegung des . Zustaiir-: 
des des in den bedingten Befehlen verwendeten Bedingungs-. 
Flags (des p-Flags) . Die Festlegung erfolgt dabei wahrend des 
Programmablauf s basierend auf einem Vergleich von zwei Daten. 
Diese Befehle werden im folgenden als pxx~Befehle bezeichnet. 

.10 Das. allgemeine Format dieser Befehle lautet: pxx <Quellen~ 
Register 1>, <Quellen-Register 2>, <p-Flag>, wobei xx die 
durchzufiahrende Vergleichsdperatiori spezifiziert und dureh gt 
(grbfier als), ge ; (grofier oder gleich) , eq (gleich), ne ; ' 
(ungleich) , le (kleiner oder gleich) oder It (kleiner als) zu 

15 ersetzen ist. Die pxx-Befehle sind lait den ublichen Branch^ 
Befehlen vergleichbar und.dienen zum Ersatz derselben durch 
die Anwendung der sogenannten if-Konversion (siehe hierzu den 
vorstehend bereits erwahnten Aufsatz von Wen-Mei W. Hwu et 
al . ) . 

20 

Die Loop-Bef ehle sind. zur Schleif enwiederholung dienende 
Befehle am Ende eines Hyperblocks. Sie veranlassen einen 
Rucksprung an den Anfang des betreffenden Hyperblocks, falls 
. eine im Befehl. spezifizierte. Bedingung erf ullt ist; sie kSn- . 

25 rieh die Generierung eines REIADY-Sighals veranlassen, wen die 
Bedingung nicht mehr erftillt ist* Die Bedingung ist durch ein 
bestimmtes Ergebnis einer Vergleichsoperation definiert- Das 
. allgfemeine Format dieser Befehle lautet: loopxx <Quellen- 
Register 1>, <Quellen"-Register 2>, wobei xx die durchzu- 

30 ftihrendei Vergleichsoperatidn spezifiziert.. ~ 

Wie aus. den Formaten der genannten Bef ehlstypen ersichtlich 
ist, werden als Daten- und/oder Signalquellen und Daten- 
und/oder Signalziele jeweils Register verwendet. Dies erweist 
35 sich bei Verwendung von Hardware-Blocken nach Art der. Figur 
12 als besonders vorteilhaf t, weil auf die Register (das 
register file 44) besonders effizient zugegriffen werden. 
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kann. Prinzipiell konnten aber auch Eefehle zugelassen wer- 
den, deren Daten^ und/oder Signalquellen und Daten- und/oder 
Signalziele keine Register sind. 

5 Viel.e Prograjncme Oder weni^^ von diesen kpnnen. 

unter. ausschlieBlicher Verwendung der vprstehend erlauterten 
Befehls-Typen geschrieben oder in solche Programme libers etzt 
werden und mithin vollstandig in einen Hardware-Block der in 
der Figur 12 gezeigten Art zur Ausftihrung gebracht werden. 

10 Die Verwendung derartiger Hardware-Blocke in programm- 

gesteuerten Einheiten kann deren Leistungsf ahigkeit daher 
erheblich steigern. Hardware-Blocke der in der Figur 12. ge- 
zeigten Art konnen jedoch aueh aulierhalb programmgesteuerter 
Einheiten als eigenstandige Einrichtungen zum Einsatz kommen 

15 und dann ebenfalls basierend auf Befehlen oder Befehlsstromen 
konfiguriert werden. 

Im folgenden wird nunmehr die Konf igurierung eines Hardware- 
Blocks beschrieben/ durch welche dieser durch Befehle oder 
20 Befehlsfolgen vorgeigebene arithmetische und/oder. logische 
Operationen oder Operationsfolgen ausftihren kann. 

Der Hardware-Block, genauer gesagt dessen Teileinheiten - 
(arithmetische Einheiten, Vergleichs-Einheiten, . Multiplexer, 

25 Demultiplexer . . . ) und die Verbindungen zwischen den Teil- 
einheiten werden im betrachteten Beispiel durch die ge- 
wunschte Konf iguratibn reprasentierenden Konf igurations-Daten 
(Konfigurations-Bits) konf iguriert . Dementsprechend ist es 
die Auf gabe des nachfolgend beschriebenen Konf igurations- 

30 Verfahrens, die Konf igurations-Daten . bzw. einen diese ent-/ 
haltenden Bitstrom. basierend auf . den. der Hardware-Block- 
Konfiguration zugrundezulegenden Befehlen oder Befehlsfolgen 
zu generieren oder zu variieren. 



35 



Iia betrachteten Beispiel wird dayon ausgegangen, daB aus- . 
schlieBlich die vorstehend genannten Typen yon Befehlen, d.h. 
normale Befehle, bedingte Befehle, pxx-Befehle und loopxx- 
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Befehle umgesetzt werden;. andere Befehle miissen anderweitig 
ausgefiihrt werden, beispielsweise durch die AusfUhrxings- 
einheit einer herkoirimlichen, programmgesteuerten Einheit • 

5 Fur die Umsetzung der ijms^ Befehle in' entsprecheh^ 

Hardware-Block-Strukturen kann.es sich als vqrteilhaft erwei- 
sen, wenn die Befehle von Haus aus ein in den Figuren lA 
(normale Befehle), IB (bedingte Befehle) , IC (pxx-Befehle) , 
und ID (loopxx-Bef ehle) beispielhaft veranschaulichtes ein- 
10 heitliches Format aufweisen oder diirch eihen Decodierer in 
ein solches Format gebracht werden* 

Insbesondere wenn die Teileinheitendes Hardware-Blocks 
konf igurierbar sind, werden diesen (physikalischen) Teil- 

15 einheiten logische bzw,. virtuelle Einheiten zugeordnet, wobei 
die virtuellen Einheiten die verschiedenen Funktionen der - 
physikalischen Teileinheiten angeben. Der physikalischen 
Teileinheit "erste arithmetische. Einheit AUl" konnen - sofern 
diese konf igurierbar ist - beispielsweise die virtuellen Ein- 

20 he: ten Addlerer, Subtrahierer etc. zugeordnet sein. Eine 

virtuelle Einheit ist genau einer physikalischen Teileinheit 
zugeordnet, aber einer physikalischen Teileinheit kannen 
mehrere virtuelle Einheiten zugeordnet s.ein. Samtliche vir- 
tuellen Einheiten werden vorzugsweise in einer Tabelle oder 

25 Liste verwaltet. Die jeweiligen Eiritrage enthalten neben 

Informationen zu den virtuellen Einheiten selbst auch Infor-- 
mation daruber, welcher physikalischen Teileinheit. die jewei- 
ligen virtuellen Einheiten zugeordnet , sind, tlb.er welche -. 
Konfigurations-Bits und wie diese physikalische Teileinheit 

30 gegebenenfalls konfiguriert werden muB, um ihr die durch die 
virtuelle Einheit reprasentierte Funktion zu verleihen. 

Vorzugsweise wird ein kompletter Hyperblock in ein^ Hardware- 
Block-Struktur umgesetzt. 

35 



:Die Umsetzung eines Befehls in eine Hardware-Block-Struktu- 
rierungsinformationen erfolgt im wesentlichen in drei Phasen. 
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In dei: ersteh Phase wird zunachst ermittelt; welchef Typ von 
virtueller Einheit (Addierer, Subtrahierer, Multiplizierer 
. j zur Ausftlhruiig deir betreffenden Ihstfuktiori benStlgt ' 
5^ wird, lihd bb eirie solche virtuell^^ rioch ' verf ugbar. 

ist. 1st noch eine yirtuelle Einheit des benotigten Typs 
frei, so wird diese oder eine von diesen zur Ausfuhrung der 
betreffenden Instruktion ausgewahlt. Sodann erfolgen die Kon- 
figuration oder deren Vorbereitung und eine Reservierung der 

,1.0 der ausgewahlten virtuellen Einheit zugeordneten physikali- 
schen Teileinheit. Zur Konf iguration werden einfach die der 
betreffenden physikalischen Teileinheit zugeordneten Konf i.gu- 
• rations-fiits gesetzt oder zuruckgesetzt ; dies bereitet keine 
Schwierigkeiten, denn die Inf ormationen, welcher physikali- 

15 schen Teileinheit die ausgewahlte virtuelle Einheit zugeord- 
net ist, iiber welche Konf igurations-Bits und wie diese physi- 
kalische Teileinheit gegebenenf alls zu konf igurieren ist , 
werden ja zusainmen mit der virtuellen Einheit verwaltet. Die 
Reservierung der der. ausgewahlten virtuellen Einheit zugeord- 

20 neten physikalischen Teileinheit ist notwendig, um zu verhin-- 
dern, dafi die betreffende physikalische Teileinheit mehrfach 
verwendet werden kann. Im betrachteten. Beispiel wird dies . 
dadurch bewerkstelligt/ dafi nach jeder Vergabe einer physi- 
kalischen Teileinheit fur einen bestimmten Zweck samtliche 

25 virtuellen Eihheiten, die der. betreffenden physikalischen 
Teileinheit zugeordnet sind, gesperrt werden. 

Bei pxx-Bef ehlen . kann es je nach dem Aufbau des Hardware- 
Blocks erforderlich sein, abhangig vom p-Flag eine ganz be- 
30 stimitite physikalische Teileinheit (Vergleichs-Einheit ) aus- 
. zuwahlen. 

Bei bedingten Befehlen wirkt sich das p-Flag nur dann auf die 
Auswahl der virtuellen/physikalischen Einheit (en) aus, wenn 
35 bestimmte Inistruktionen nur mit bestimmten Flags moglich 
sind, also keine vollstandige Orthogonalitat in dem Teil- 
befehlssatz fUr bedingte Befehle vorhanden ist. 
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In der zweiten Phase der Hardware-Block-Konf igiirierxing werden 
die den ausgewahlten physikalischen Teileinheiten vor- 
uhd/oder nachgeschalteten Multipleker konfiguriertV 
5 Daten- und/oder Sigiialquellen.und die und/bder Sigrial- 

ziele entsprechend den Festlegungen in den timzusetzenden 
Instruktionen einzustellen. Die Multiplexer und das Format 
der umzusetzenden Instruktionen sind im Idealfall so anein- 
ander angepaBt, daii die die Daten- und/oder Signalquellen und 

10^ die die . Daten- und/oder Signalziele festlegenden Telle der 

Instruktionen unverandert als die die Multiplexer konfigurie- 
renden Konfigurations-Bits ubernommen werden konnen. . Ist -dieis 

aus welchem Gruhd auch immer - nicht moglich, konnen die 
die Multiplexer konf igurierenden Konf igurations-Bits bei- 

15 spielsweise einer Tabelle entnommen werden, in welcher die 

Zuordnung zwischen den die Daten- und/oder Signalquellen und 
die Daten- und/oder Signalziele festlegenden Teilen der 
Instruktionen und den die Multiplexer konf igurierenden Kon- 
figurations-Bits gespeichert ist. Die Konf igurierung, die 

20 erforderlich. ist, um eine Verbindung zu einer bestimmten 
Daten- und/oder Signalquelle und/oder zu einem bestimmten 
Daten- und/oder Signalziel herzustellen, ist vcrzugsweise fUr 
alle^. Multiplexer gleich. 

25 Eine gesonderte Behahdlung ist notwendig, Wenn die der aus- 
zufuhrenden Operation zugrundezulegenden Daten zumindest 
teilweise aus einer im Instruktions-Code enthaltenen Kon- 
stanten bestehen. Dann muB 

- ein freies (Konstanten-) Register gesucht werden,. 

30 - dieses Register als Daten- und/oder Signalquelle verwendet 
werden, und 

- die im Instruktions-Code enthaltene Konstante vor der 
Inbetriebhahme des UCB in das ausgewahlte Register ein- 
geschrieben werden. 

35 

Im betrachteten Beispiel wird vorab tlberprtlft, ob die be- 
treffende Konstante schon in einem (Konstant en-) Register 
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gespeichert ist. Ergibt sich dabei, daB bereits ein die Kon- 
stahte enthaltendes (Konstanten-) Register existiert/ so. wird 
dieses schon existierende (Konstanten-) Register als Daten- 
unid/oder Signalquelle verwendet 

Zu beachten ist ferner, dafi die nmzusetzenden Instruktionen . 
unterschiedlich viele Daten- und/oder Signalquellen und 
Daten- und/oder Signalziele aufweisen und/oder von Bedingun- . 
gen abhangen und insofern eine Sonderbehandlung der einzelnen 
Ins.truktiojien erforderlich ist.. 

Als Daten-^ und/oder Sicrnalziel verwendete Register werden 
ubrigens als belegt markiert, da ihnerhalb eines Hyperblocks 
keine Zweitbelegung zulassig ist und durch ein sogenanntes 
(Runtime) Register Renaming, einer aus superskalaren Archi- 
tekturen bekannten Technologies verhindert werden muB. 

Nach dieser (fiir alle Befehle gemeinsamen) zweiten Phase wer- 
den fiir einzelne Befehlstypen spezielle Teilschritte einge- 
fiigt, die sich aus den jeweiligen Besonderheiten ergeben. 

Unter anderem muB bei bedirigten Befehlen die das Vorliegen 
der Bedingung Uberprtif ende Vergleichs-Einheit ermittelt wer- 
den und. deren. Ausgangs signal uber den. zugehdrigen Demulti- 
plexer auf die die Operation ausfUhrende arithmetische 
Einheit geschaitet werden. Ferner ist zu berUcksichtigen, 
welcher Art die Bedingung. ist. 

Bei bedingten Mpve-Bef ehlen ist zusatzlich daftlr Sorge zu 
tragen, daB der Inhalt des Zielregisters bei Nicht-AusfUhrung 
des Befehls nicht verandert wird. 

Nach der zweiten . Phase • der Hardware-Block-Konf igurierung: 
k5nnte diese beendet und der Hardware-Block gestartet werden. 
Dies geschieht vorzugsweise jedoch erst nach der Ausfiihrung 
der nachfolgend beschriebenen dritten Phase. 
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In dieser dritten Phase der Hardware-Block-Konf igurierung. 
wird ein sogenanntes data forwarding realisiert. Dabei werden 
als Daten- und/oder Signalquellen nicht stur die in den In- 
struktioneh angegebenen Daten- und/oder Signalquellen verwen^" 
5 ■ det, sonderh nach; Moglichkeit die physikalische Teileinheit;- 
die die betreffende Daten- und/oder Signalquelle innerhalb 
des jeweiligen Hyperblocks zuvor . zu beschreiben hatte. Dies 
erweist sich in zweifacher Hinsicht als vorteilhaft: einer- 
seits, weil eventuell weniger Register benotigt werden (wenn 

.10 die in der Instruktion angegebene Daten- und/oder Signal- 
quelle nicht als solche'verwendet wird, mufi sie auch nicht 
• besGhrieben werden und kann gegebenenf alls ganz weggelassen 
werden), und andererseits, weil die benotigten Daten bei Ab- 
holung von der diese erzeugenden Teileinheit (beispielsweise 

15 einer arithmetischen Einheit) fruher verfugbar sind als wenn 
sie zuerst in ein Register geschrieben . und von dort abgeholt. 
werden mussen. Das data forwarding^ kann bei alien Befehlen 
zur Anwendung kommen und erweist sich im Durchschnitt als 
enormer Vorteil . 

20 

Das. soeben kurz in Worten beschriebene Verf ahren laBt sich 
auch durch dessen sof twaremaBige und dessen hardwaremaBige 
Realisierungsia5glichkeiten und in mathematischer Notation 
veranschaulichen i 

25 ' '■' . ■ - • ■ ■ ■■ ■■' ■ -"^ 

Zunachst soil eine sbf twaremaBige Realisierung in einer C++- 
ahnlichen Darstellung. be schrieben werden. Im betrachteten 
Beispiel erfolgt die Ve r wait ung der Inf ormationen zu den 
Hardware-Block-Kpnf igurationsdaten durch Klassen. 

■-30 

Die Klasse fUr eine virtuelle Einheit wird im betrachteten 
Beispiel folgendermaBen definiert: 

class clVirtualUnit { 
35 private: unsigned int uiPhysicalPartNumber; 

unsigned int uiMnemonicType; 
BOOL bIsConfigurable; 
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\insigned int uiConfBits; 
unsigned int uiConfBitsIndex; 
BOOL bTwoSourceRegs; 

unsigned irit uiSrcMultiplexNiamber [2] ; 

unsigned int uiSrcMultiplexIndext • 

BOOL bDestinationReg; . 

unsigned int uiDestMultiplexNuitiber; 

unsigned int uiDestMultiplexIndex; 

BOOL bIsUsed; 

BOOL bSecbndPIsused; 

BOOL bIsConstantRegister; 

unsigned int uiConstantlndex; 

unsigned int uiConst an tValue; 

unsigned int uiGetPartNumber ( void ); 
unsigned int uiGetMnemonicType { void ) ; 
BOOL bIsUnitConfigurable ( void ); 
unsigned int uiGetConfBits ( void ) ; 
unsigned int uiGetConfBi ts Index ( void ); 
BOOL bHasTwoSburceRegs ( void ) ; 
unsigned int uiGetSrcMultiplexNTimber 

( lonsigned int ) ; 
unsigned int uiGetSrcMultiplexIndex 

( unsigned int ) ; 
BOOL bH^sDestinationReg ( void ); 
unsigned int uiGetDestMultiplexNumber ( void" ) 
unsigned int uiGetDestMultiplexIndex ( void ); 
void vFreePart( void ); 
BOOL bMarkUsedPart ( void ) ; 
BOOL bMarkSecondUsedFi ag ( void ); 
BOOL bGetIsUsed( void ); 
BOOL bGet IsUsedSecondFlag ( void ) ; 
BOOL bIsConstantRegister (void ); 
BOOL bSetConstantValue( void ); 
unsigned int uiGetConstantValue { void ) ; 
unsigned int uiGetConstantlndex ( void ) ; ^ 
} 
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Die in der Klasse enthaltenen Daten tand Methoden dieneii zur 
. Modellierung einer Mikroarchitektur. 

'."5 -' ' ■ ■ ■ . ■ ^ ■" ' '" ' " • • ; ^•■ ■ 

■ Vpti den Daten bedeuten: 

uiPhysicalPartNiimber : Diese Variable enthalt eihe eindeutige 
Nuinmer fur die physikalische Teileinheit innerhalb des 
10 ... Hardware-Blocjcs.-; . . . 

. uiMneinonicType: Diese Variable enthalt in codierter/ Form den 
Verknupfungstyp, der zu der jeweiligeri virtueillen Eiri- 
heit gehort . 
15 ^ 

bIsConf igurable : Dieses Flag zeigt an, ob die zugehorige phy- 
sikalische Teileinheit konfiguriert werden muB, um diese 
virtuelle Einheit zu erhalten. 

20 uiConfBits: Falls bIsConf igurable == TRUE ist, werden hier 
die zugehorigen Konf igurationsbits gespeichert, iim die 
physikalische Teileinheit ftlr exakt . diese\ Funktion. zu 
konf igurieren . 

25 UiConfBits Index: Falls bIsConf igurable == TRUE ist, wird der 
Index zur Speicherung der Konf igurationsbits im Bitstrom 
an dieser Stelle gespeichert. 

bTwoSourceRegs : Dieses Flag wird auf TRUE gesetzt, falls fiir 
30 den betreffenden Befehl zwei Sourceregister angegeben 

werden mUssen/ ansonsten auf FALSE • 

uiSrcMultiplexNuinber [2] : Bei zwei Sourceregisterii werden die 
physikalischen Nummern der zugehorigen Multiplexer in 
35 dieser Variablen gespeichert/ gegebenenf alls ist nur die 

Variable mit diem Index 0 giiltig. 
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uiSrcMultiplexIndex [2] : Hier werden die Indizes der Multi- 
plexer fur die Sourceregister gespeichert. 

bDestihatiohRegt Dieses Flag Wird auf TRUE gesetzt, falls fur' 
• den betreffenderi Befehl ein Destinationregister (nicht - 
flag! ) angegeben werden mufi/ ansonsten auf FALSE. . . 

uiDestMultiplexNumber : Hier wird die physikalische Nummer des 
zugehorigen Multiplexers fur das Zielregister gespei- 
chert. .... . 

uiDestMultiplexIndex : Hier wird der Index des Multiplexer:.. .fur 
- das Destinationregister. gespeichert.. 

bIsUsed: In diesem Flag wird gespeichert, ob diese virtuelle 
(und damit zugleich die physikalische) Teileinheit be- 
. nutzt wurde. .Ein Setzen dieses Flags auf TRUE bedeutet, 
daB diese Teileinheit nicht mehr. genutzt werden kann 
(auJier bei den bedingten Move-Bef ehlen (movep) ) . 

bSecondPIsUsed: Fur den Sonderfall. der movep-Befehle wird in 
dieseia Flag die zweite Nutzung eines. p-Flags einschlieB- 
lich des Vergleichs gespeichert. Sirid bIsUsed und 
. bSecondPIsUsed auf TRUE gesetzt, ist der dynamische 
Wegmultiplexer (AU) , auf den eiri movep-Bef ehl abgebildet 
wird/ zur weiteren Nutzung gesperrt. 

bIsConstantRegister : Dieses Flag zeigt an, daB die physikali- 
sche Teileinheit einem Konstantenregister entspricht 
. (TRUE) Oder nicht (FALSE) . 

uiConstantlndex: Im Fall eines Konstantenregisters muB der 

Wert der Konstanten, der gespeichert und genutzt werden 
soil, im Bit Strom eingetragen werden. In diesem Fall ist 
der Index im Bitstrom in dieser Variablen gespeichert. 
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uiConstantValue: Der Wert, der im Konstantenregister gespei- 
chert wird/ wiird ftir weitere Vergleiche zusatziich in 
dieser Variablen der' Instanz gespeichert. 

Die in einer Instanz dieser Klasse auf tr'eteiiden Variablen ^ 
mussen alle ziim Zeitpunkt des Starts der Konfiguratipn belegt 
werden. Hierzu werden hier nicht explxzit aufgeftihrte Metho- 
den benutzt, die im Konstruktor einer nachfolgend erlauterten 
Configurable-Block- bzw. CB-Klasse genutzt werden, um alle 
fur die Umsetz.ung notwendigen Inf ormationen in die Instanz zu 
schreiben und zugleich die Flags bIsUsed und bSecondPIsUsed . 
auf. FALSE zu setzen. Wahrend der Lebenszeit .;dieser Instanz 
andern sich dann nur noch diese beiden Flags, die tiber Vor- 
definierte Methoden mit dem Wert TRUE bzw. FALSE belegbar 
sind, sowie - im Fall eines Konstantenregisters - die 
Variable uiConstantValue, in der der aktuelle Wert des Regi- 
sters fur weitere Vergleiche zwischengespeichert wird. 

Von den Methoden der vorstehend definierten Klasse ftir die 
virtuellen Einheiten bedeuten: 

unsigned int uiGetPartNumber ( void ): Diese Methode gestattet 
den iesenden Zugriff auf die Nummer der zur virtuellen 
Teileinheit gehorenden physikalischen Teileihheit; die 
Nummer wird als Rtickgabewert zurtickgelief ert . 

unsigned int uiGetMnemonicType ( void ) : Diese Methode. gestat- 
tet den Iesenden Zugriff auf Mnemonic, der in der vir- 
tuellen Einheit implemehtiert werden kann, 

BOOL bIsUnitConfigurable( void ): Diese Methode lief ert TRUE, 
falls die physikalische Teileinheit konfiguriert werden 
mufi , Unter dies en. Urns tanden sind die Eintrage in uiConf- 
Bits \ind uiConf Bits Index gtiltig und k5nnen mit den fol- 
genden Methoden uiGetConf Bits {) und uiGetConfBitsIndexO 
erhalten werden. Ferner mtiissen alle anderen virtuellen 
Teileinheiten, die zuir gleichen physikalischen Einheit 
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gehoren, ebenfalls gesperrt werden. Fur den Rtickgabewert 
FALSE hingegen sind virtuelle und physikalische Einheit 
identisch. 

unsigned Vint uiGetConfBits ( void ) : Dureh diese Methode wer- 
. den .-die Konfigurationsbits gelesen und als Riickgabewert . . 
zurtickgeliefert . Diese Werte sind nur giiltig^ wenn 
bIsConf igurable den Wert TRUE besitzt. 

unsigned int uiGetConfBitsIndex ( void ): Durch diese Methode 
wird der Index im Bitstrom fur die Konf igurationsbits 
gelesen und als Rtickgabewert zurtickgeliefert. Dieser 
/ Wert ist nur gtiltig, wenn. bIsConf igurable den Wert TRUE 
besitzt, 

BOOL bHasTwoSourceRegs ( void ) : Ein Auf ruf dieser Methode 
liefert den Wert TRUE, falls diese Operation zwei 
Sourceregister besitzt xind diese. in die entsprechendeh 
Multiplexer einzutragen sind, ansonsten den Wert FALSE ^ 

unsigned int uiGetSrcMultiplexNuiaber ( unsigned int ) : Diese 
Methode liefert die Nummer der physi kalis chen Tell- 
einheit, die den Multiplexer fur die Sourceregister dar- 
stellt. Auf ruf parameter ist der Index in. dein- Array von 2 
Eintrageh, wobei der Index 1 nur gultige Werte liefert, 
falls das Flag bHasTwoSourceRegs .den Wert TRUE besitzt. 

unsigned int uiGetSrcMultiplexIndex ( unsigned int ) : Diese 
Methode lief ert den Index zum Eintrag in den Bitstrom, 
um die Konf igurie rung des Multiplexers ftir die Source- 
register vorxiehmen zukonnen. Auf ruf parameter ist der 
Index in dem Array von 2 Eintragen, wobei der Index . 1. 
nur gUltige Werte liefert, falls, das Flag bHasTwoSource- 
Regs den Wert TRUE besitzt. 

BOOL bHasDestinationReg( void ) : Ein Auf ruf dieser Methode 

liefert den Wert TRUE, falls diese Operation ein Desti- 
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nationregister besitzt und dies in den entsprechenden 
Multiplexer einzutragen ist, ansonsten den Wert FALSE. 

unsigned int uiGetDestMultiplexNuinber ( void ) : Diese Methode 
' liefert die Nummer der physikalischen Teileinheit, die 
den Multiplexer: ftir das Destinatiqnregister . darstellt 
Der Rtickgabewert ist nur gtiltig, falls das Flag bHas- 
DestinationReg den Wert TRUE besitzt. 

unsigned int uiGetDestMultiplexlndex { void ) : Diese Methode 
liefert den Index zum Eintrag in den Bitstrom, um die 
konfigurierung.des Multiplexers ^ fur das Destination- 
register vornehmen zu konneni Der Ruckgabewert ist nur 
giiltig, falls das Flag bHasbestinationReg den Wert TRUE 
besitzti 

void vFreePart( void ): Diese Methode loscht alle Belegungs- 
flags, Indem diese mit dem Wert . FALSE belegt werden, 
Hierin erfolgt also ein schreibender Zugriff auf die 
Flags • 

BOOL bMarkUsedPart ( void ): Das Belegtflag bIsUsed wird .tiber 
diese Methode auf TRUE gesetzt . Ruckgabewert ist TRUE, 
falls die Operation erf olgreich war, FALSE, falls dieses 
Element bereits belegt war. 

BOOL bMarkSecondUsedFlag( void ): Das zweite Belegtflag 

bSecondPIsUsed wird entsprechend auf TRUE gesetzt. Ruck- 
gabewert ist auch hier TRUE, falls die Operation erfolg- 
reich war, FALSE, falls dieses Element bereits belegt 
war . . ■ 

BOOL bGetIsUsed( void ): Diese Methode liefert als Ruckgabe- 
wert den Wert der Variablen bIsUsed. 

BOOL bGetIsUsedSecondFlag( void ): Diese Methode liefert als 
Ruckgabewert den W^rt der Variablen bSecondPIsUsed. 
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BOOL bIsConstantRegister( void ) : Diese Methode gibt TRUE zu- 
rtick, falls die virtuelle Teileinheit einem Konstanten-- 
register entspricht/ ansonsten FALSE. 

BOOL bSetConstantValue { void ) : Mit Hilfe dieser Methode kann 
der aktuelle Konstanterxwert in der Variablen uiConstant- 
Value gespeichert werden, falls diese virtuelle Einheit 
einem Konstantenregister entspricht und dieses bisher 
nbch nicht belegt wurde.. Ruckgabewert ist TRUE fiir Er- 
folg, FALSE sonst. 

unsigned int uiGetConstantValue ( void ) : Mit Hilf e dieser 

Methode wird der gespeicherte Konstantenwert zuruckgege- 
ben. 

unsigned int uiGetConstantlndex ( void ): Der Index in den 
Bit Strom/ der ftir die Speicherung des Konstantenwerts 
dort notwendig ist, wird Uber diese Methode erhalten. 

FUr die Modellierung eines Hardware-Blocks (CBs) wird eine. 
zweiteJKlasse definiert/ die u.a. Instanzen der Klasse 
clVirtualUnit sowie weitere Variablen und Methoden enthalt. 
Zur Vereinfachung wird eine Speicherung der Elemente in einem 
statischen Array angendmmen; eine verkettete tiste ist nkttif- 
lich ebenfalls denkbar. Es sei an dieser Stelle angemerkt, 
daB fur die hier angegebenen Klassen nur eiri Teil der Metho- 
den dargestellt wird. 

class clCB 

■ '"• - \ - * ■ • ■ '.- ^ 
private: BITFIELD *clbitfield; 

class ClVirtualUnit clArrayVirtualUhits 

[NUM_OF_PARfs] ; 



public: 



clCB ( ); 

void vSetupBitf ield( BITFIELD *); 
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void vFreeAll ( void ) ; 
BOOL bDoAllPhase_l_Parts 

{ unsigned int, BITFIELD * ) 
BOOL bDoCoinmonPhase^2_Parts ( unsigned int; 

• BITFIELD */ , 
. unsigned int/ 
unsigned int, 
unsigned int ) ; 
void vDataForwarding ( unsigned int, unsigned int ); 
void vCopyBitfield( BITFIELD *, BITFIELD * ); 
unsigned int uiGetMiixCode ( unsigned int, 

unsigned int ) r 
unsigned int uiGetRegPartNumFromCode ^ 

( unsigned int ); 
. unsigned int uiGetPartNumFromFlag 

( unsigned int ) ; 
unsigned int uiGetIndexFroinNum{ unsigned int ) ; 
unsigned int uiGetPartNumFromBitf ield . 

( unsigned int ); 
void vSetBitf ield ( unsigned int, unsigned int, 

unsigned int ) ; 



Die Variablen und Methoden der Klasse clCB bedeuteh im. eih- 
zelnen: 

BITFIELD *clBitfield: Diese Variable entspricht dem zu gene- 
. rierenden Bitstrom ftir eine Lauf zeitkonf iguration. dies 
CB- ; /; 

class clVirtualUnit clArrayVirtua;iUnits [NUM_OF_PARTS] : Dieses 
Array von Instanzeri der Klasse clVirtualUnit enthait 
alle Informationen fur alle virtuellen Einheiten iind 
somit. auch ftir alle physikalischen Teileinheiten, 
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clCiBO: Dieser Kpnstruktor wurde aufgefiihrt, um zu verdeutli- 
Chen, woriri die Aufgaberi dieser Klasse bestehen. In 
eiher Startphase mtisisen sbwohl das iBitfeld als auch alle 
instanzeri der "Klasse ciyirtuklUhit , die im Array 
5 clArrayVirtualUnits [ ] zusaniihengef aJJt we'rden/ ini-:. : 

tialisiert -werden. : Zur Ini Klassen- 
instanzen zahlen insbesondere das Beschreiben aller 
Konfigurationsdaten sowie das Rticksetzen aller Flags, tun 
in der Betriebsphase auf die notwendigen Daten lesend 
10 . zugreifen zu konnen.. 

void vSetupBitfield( BITFIELD * ) : In dieser Methode wiird das 
Bitfeld mit alien Vorbelegungen versorgt.: 

15 void vFreeAll ( void ): Diese Methode wird zum Loschen aller 
- . Belegtf lags in dem Array clArrayVirtualUnits [ ] aufgeru- 
fen. 

BOOL bDoAllPhase_l_Parts (unsigned int, BITFIELD * ) : In die- 
20 ser Methode . sind alle Telle zur Phase 1 zusainmengef afit . 

Sie wird aufgerufen, liachdem eine freie Teileinheit zur 
Aufnahme des Mnemonics gefundien wurde und enthalt die 
Markierung aller zugehOrigen virtuellen Einheiten als 
beset zt, Best:inimung der Konfigura des Index 

25 in den Bitstrom und Eintragurig in einen tempo rar en 

Bitstrom. Parameter sind der Index in dem Array der vir- 
tuellen Einheiten und der Zeiger auf den temporaren 
Bitstrom. Der Rttckgabewert TRUE zeigt eine erfolgreiche 
Phase 1 an, FALiSE d^n MiBerfolg (etwk durch nicht aiis- 
30 reichehde Netzressburcen) . 

BOOL bDoCommonPhase_2_Parts ( unsigned int, BITFIELD *, 

unsigned int, unsigned int, unsigned int) : Diese Methode 
fafit die ftir alle Bef ehlsgruppen gemeinsamen Methoden 
35 zusammen. Hierzu zahlen die Eintrage ftir die Source- und 

Destinationregister einschlieBlich der Behandlung. der 
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Konstanten als Eingabewerte. RQcicgabewert ist TRUE fUr 
Erfolg und FALSE fur Miflerfolg. 

void vDataForwarding ( unsigned int, unsigned int): Die Be- 
rechnuhg des Data Forwarding lait alien zugehorigen 
Methodeh ist in dieter Methode integriert / Die Voir- 
gehensweise betrifft die Sourceregister, deren physika- 
lische Nuininer in den Parametern tlbergeben. werden. Unter 
Nutzung weiterer Methoden wird ermittielt, ob ein Source- 
register bereits.ein frtiheres Destinationregister war. 
Ist dies der Fall, wird die letzte berechnehde AU aus 
dem Bitstrom ermittelt und anstelle des. Registers ein- 
getragen. 

void vCopyBitf ield( BITFIELD *, BITFIELD *) : Diese Methode 

verknupft die Eintragung in dem zweiten Bitstrom mittels 
ODER lait denen des ersten und speichert das Ergebnis im 
ersten Bitstrom, Hierdurch wird das temporare Zwischen- 
ergebnis im zur spateren Konf iguration berechneten 
Bitstrom gespeichert. 

unsigned int uiGetMuxCodel unsigned int, unsigned int) : Diese 
Method^ berechnet die Konf igurationsbits, die far einen 
Multiplexer in den Bitstrom zu laden sind, urn als Quelle 
eine physikalische Teileinheit auszuwahlen. Parameter 
dieser Methode sind die physikalische Nummer des Multi- 
plexers sowie der Quelleinheit. Diese Methode ist un- 
bedingt notwendig zur Konf iguration> da in der Beschrei- 
bung der virtuellen Einheiten zwar der Index des Ein- 
trags/ nicht jedoch der Eintrag selbst gespeichert wird. 
Diese Methode kann fUr ein vollstSndiges Netzwerk als 
tabellengestatzte Umrechnung gegebenenf alls ohne Bertick- 
sichtigung der Multiplexerniommer implementiert sein, da 
in diesem Fall alle Multiplexer auf einheitliche Weise : 
konfigurierbar sind. FUr partielle Netzwerke muB hier 
groBerer Aufwand betrieben werden, insbesondere kann 
eine Vernetzung unmoglich sein. RUckgabewert sind die 
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Konfigurationsbits iin Erfolgsfall bzw. eine sonst un- 
genutzte Codierung fiir deii Fall des MiBerfplgs. 



unsigned int uiGetRegPartNumFromCode (unsigned int) : Diese 
5 MethodiB berechnet die Nuinmer der Teileinheit aus dem 

Code in der Iris trttktibn Dies ka:nri haturgemafi niir ftlr 
Register erfolgen, wobei iin Fall einer Konstanten die 
beschriebene Vorgehensweise in dieser Methode integriert 
ist, die zur Speicherung der Konstanten und zur Ruckgabe 
• lb - der physikalischen Nuiniaer des . Konstantenregisters fiihrt. 
Riickgabewerte sind die Nuinmer der Teileinheit. im Er- 
folgsfall, ansonsten eine nicht benutzte Kennung ftir den 
Mifierfolg. = . 

15 unsigned int uiGetPartNuitiFromFlag (unsigned int ) : Fiir die Um- 
rechnung einer Flagnummer in di^e^Nummer der physikali- 
schen Teileinheit ist diese Methode zustandig. Aufruf- 
parameter ist das p-Feld in dem Instruktionsf ormat, 
RUckgabewert die Teileinheitsnummer oder eine besondere 

20 Kennung im Fall des Mifierfolgs. 

. unsigned int uiGetlndexFromNum (unsigned int): Mit Hilfe die-, 
ser Methode wird der Index in den Bitstrom ftir eine 
Teileinheit mit bekannterphysikalischerNvimmer (als 
25 Paraineter) berechnet und zurUckgegeben. Diese Berechnung 

kann in Tabellenform erfolgen, 

unsigned int uiGetPartNumFremBilfield (unsigned int) : Diese 
Methode liest den Eihtrag in dem Bitfeld an dem als 

30 Parameter libergebenen Index und rechnet die erhaltene 

Konf igiirationsmaske in die physikalische Numiner der 
Teileinheit zurtlck, die als Ergebnis zurUckgegeben wird. 
uiGetPartNumFrpmBitfield wird im Data Forwarding ein- 
gesetzt/ wo der Datenweg von eiriem frtiheren Zielregister 

35 auf die das Ergebnis bestimmende Teileinheit zurUck- 

verfolgt wird/ damit die Daten vorzeitig verwendbar 
sind. 
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void vSetBitf ield { iihsigned int, unsigned int, unsigned int) : 
Diese Methode wird mit drei Parametern aufgerufen: Der 
. . Index der Eintrags, die Lange des Eintrags und die 
5 Maske. Der Aufruf bewirkt deil Eihtrag in dem Bitfeldan 

der entsprechenden Stelle* 

Mit den vorstehend genannten und erlauterteh Variablen und 
Methoden ergibt sich folgender . Pseudocode fiir das Verfahren- 
10 zur der auf Befehlen oder Befehlsfolgen basierenden Konfigu- 
rierung eines Hardware-Blocks der in der Figur. 12 dargestell- 
" ten Art ( f tir die struktur-^prozedurale Programmierung) : 

unsigned int k; 
15 BITFIELD *clTempBitfield; 

// !• Phase: Bestimmung einer physikalischen Teileinheit zur 
// Aufnahme der Verkniipfung. 
// mnenomic in uiMem stehend 

20 

v3etupBitf ield( clTempBitf ield ) ; 

for( k. = 0; k < NUM_OF_PARTS; k++ ) ' 

25 if { clArrayVirtuaiUnits [k] : :uiGetMnenomic () == uiMem 

&& clArrayVitualUnit [k] : rbGetlsUsedO == FALSE ) 
break; 

}■'■•-■ 

30 if( k == NUM_OF_PARTS ) // Keine freie VerknUpfung gefunden 
return ( FALSE ) ; 

// Jetzt wird die freie Teileinheit als besetzt markiert, 
// gegebenenf ails eine Konf igurierung bestimmt und in diesem 
35 // Fall auch alle anderen virtuellen Einheiten als besetzt 
// markiert. Alle Maskenbits werden in einem temporairen 
// Bitstrbm gespeichert* 
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if ( bboAilPhase_l_Parts { k, clTempBit field ) == FALSE ) 
return ( FALSE ) ; . 

// Nuhmehr beginnt die zweite Phase: Fur ar^^ 

// werden die beiden, gegebenenf alls ein Sourceregister 

// bestimmt und in den Bitstrom eingetragen. Entsprechendes 

// erfolgt mit dem Destinationregister, falls vorhanden. Die 

// entsprechenden Codierungen aus der Instruktion stehen in 

// den Variablen uiSourceRegl, uiSourceRegZ und uiDestReg, 

// wdbei gegebenenfalls Konstanten als Quellen hier erkennbar 

// sind. 

if( bDoPhase_2_CominonParts ( k, clTempBitf ield uiSourceRegl, 
uiSourceReg2, uiDestReg == FALSE ) 
return ( FALSE ); . 

switch ( uiMnemonicType ). 
{ 

case BEDINGTER_BEFEHL // p-Flag bestimmen, Eintrag ftir CU 
case MOVEP^BEFEHL: // spez. erster Eintrag, 

// zweiter Eiritrag moglich . 

■ ■ ■ . 

vDoDataForwarding { uiSourceRegl, uiSourceReg2 ) ; 

// Die letzte Aktion: Der temporar gespeicherte Bitstromcode 
// wird in den eigentlichen Bitstrom kopiert 

vCopyBitfield( clBitfield, clTempBit field ) ; 
return ( TRUE ) ; , 

Die yorstehende zentrale Routine wird ftlr jede Instruktion, 
die tibersetzbar ist, aufgerufen. Rtickgabewert ist TRUE, falls 
die Umsetzung gelungen is t, ansohs ten FALSE. Im letzteren 
Fall itiuB die Instruktion im aufrufenden Programm behalten 
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werderi/ da sie nicht eingefligt wurde,.und der Bitstrom kann 
zur Ausftihrung geladen werden. Das Ende einer Umsetzung wird 
also durch das Erschopfen der Ressourcen angezeigt oder durch 
eine nicht-tibersetzbare Instruktion wie beispielsweise einen 
5 Branchbefehl erhalten- 

Wie vorstehend bereits erwShnt wurde, lafit sich die struktur- 
prozedurale Programmierung nicht nur sof twaremafiig, sondern 
auch hardwaremaBig realisieren. Eine mogliche Ausfiihrungsf orm 
10 einer hardwaremaiiigen Realisierung wird nachfolgend unter Be- 
zugnahme auf~di~e7^Frguren 2 bis 10 erlauteirt. Dabei wurde ver- 
sucht, die einzelnen Phasen so weit wie moglich parallel 
durchlaufen zu lassen, 

15 Die bei der sof twaremaliigen Realisierung vorkommenden tabel- 
lengesttitzten Umrechnungen werden bei der hardwaremaBigen 
Realisierung als sogenannte Look-Up-Tables (LUTs) realisiert. 
LUTs sind dazu ausgelegt, im Ansprechen auf die Eingabe von 
Daten von diesen abhangende Daten auszugeben. Solche LUTs 

20 konnen beispielsweise durch ein EPROM oder eine andere 

Speichereinrichtung gebildet werden. Die eingegebenen Daten 
werden dann als Adresse verwendet, und die ausgegebenen Daten 
sind die unter dieseir Adresse gespeicherten Daten. 

25 FUr die er$te Phase wird eine LUT der in der Figur 2 ver- 

anschaulichten Art verwendet. Diese LUT weist zwei Eingange 
(Address/ Cpunter^Address) und vier Ausgange (Code, Comple- 
mentary, Count er_Up / No_Entry) auf. Die zwei Eingange dienen 
der Adressierung der LUT, wobei die iiber den einen Eingang 

30 (Address) zugeftihrten Daten und/oder Signale vom zu tiber- 
setzenden Code abhangen, und wobei die tiber den anderen 
Eingang (Count er^Address) zugeftihrten Daten und/oder Signale 
Zahlstande eines durch den Ausgang Couhter_Up hochzahlbaren 
Zahlers (Zahler-Arrays) sind. Die AusgSnge dienen zur Aiisgabe 

35 des tibersetzten Codes (Code) , von Signalen zum Hochzahlen des 
die Counter_Address generierendeh zahlers oder Zahler-Arrays 
(Counter_Up) , eines Signals zur Signalisierung ftir den Fall, 
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daB kein gtiltiger xind freier Eintrag mehr vorliegt 
(No_Entry) , und eines ftir die Bearbeitiing bedingter Move- 
Befehle (movep) benStigten Signals (Complementary), wobei 
sich der tibersetzte Code aus Konf igurations-Bits (Conf ig- 
5 Bits) / einem Konf igiirationsindex (Conf ig— Index) ; lind eiher 
. Teilehiimmer (Part-Number) zusammensetzt. bi^ Lodk^Up^Table-^ 
EintrStge haben damit ftir den ersten Teil das in Figur 3A 
gezeigte Format. 

10 per erwahnte Zahler (das Zahler-^Array) wird als Markierungs- 
mittel (beset zty schreibend) verwendet, wobei fur jeden 
Operations-Typen (Addition, Subtraktion /..) ein separater 
Zahler existiert. Der Zahlstand der zkhler gibt an, die 
wievielte Moglichkeit zur Ausfuhrung des zugeordneten 

15 Operations-Typs in Anspruch genommen werden kann. Die Tiefe 
der Zahler innerhalb dieses Zahler-- Arrays hangt von der An- 
zahl der Moglichkeiten zur Ausfuhrung der betreffenden 
Operation ab. Sind beispielsweise drei Additionsmoglichkeiten 
vorhanden, betragt die Zahlertiefe zwei Bit; in der korre- 

20 spondierenden LUT, die ja von dem Mnemonic-Code und dem 

Zahlerstand adressiert wird, wird dann allerdings an der 4, 
Stell.e (Zahlerstand 3) eine NO_ENTRY-Codierung stehen, urn das 
Fehlen dieser Operation anzuzeigen; ein derartiger LUT-Ein- 
trag ist in Figur. 3B veranschaulicht • 
•25' ■ ; ■ ' ' ■ • •* ^ ■■ 

Die besagten Zahler sind im betrachteten Beispiel Binarzahler 
mit asynchrpnem Reset und Enable. Ein 2-Bit-Binair zahler die- 
ser Art ist im betrachteten Beispiel wie folgt codiert; die 
Darstellung erfolgt in dem bei DNF{Disjunktive Normal-Form) - 

30 Logiken gebrauchlichen DNF- Format. Zahler dieser Art werden 
im folgenden als Zahler eines ersten Typs bezeichnet. 

BIT bO, bl:OUT; 
BIT reset, enable: IN; 
35 BIT clock: IN; 

bO = /bO * enable + bO * /enable; 



wo 00n7771 



PCT/DE99/02878 



37: 

bO.clk = clock; 
bO.areset = reset;. 

- bl.= bO * enable +bl * /bO * enable + bl * /enable; 

5 bl.clk = clock; 

bi. areset = reiset; 

Parallel zu diesen Zahlern muB ftir die bedingten Befehle ein 
Speicher^rray implementiert sein, um den Code des Bedihgungs 

10 flags speichern- zu kQniien. Dies ist, wie vorstehend bereits 
erlautert wurde, zur Zusammensetzung von Movep-Bef ehlen not- 
wendig. Da es nur eine CU-Instanz pro Flag gebenkahn (im 
Gegensatz zu den AUs gibt es zwar im allgemeinen mehrere 
Flags, die sich jedoch alle durch die Bezeichnung des Bits 

15 unterscheiden) , besteht der Binarzahler aus zwei Bits, von. 
denen das erste die Erstbelegung, und das zweite die Kpmple- 
mentarbelegung anzeigt. Die Identif izierung der kdrrekten CU 
erfolgt anhand der p~Bits aus dem Befehl. 

20 Die 2-Bit--Binarzahler fiir bedingte Move-Befehle sind im 
betrachteten Beispiel wie folgt codiert; die Darstellung 
erfolgt wiederum in dem bei DNF (Dis junktive Normal-Form) - 
Logiken gebrauchlichen DNF- Format. Zahler dieser Art werden 
im folgenden als Zahler eines zweiten Typs bezeichnet. 

25 

BIT bO> blrOUT; 

BIT reset, enable: IN; 

BIT clockrIN; 

30 bO = /bO * enable + bO; 
bO.clk = clock; 
bO.areset = reset; 

bl = /bl * bO * enable + bl; 
35 bl.clk = clock; 

bl. areset = reset; 



wo 00/17771 



PCT/DE99/02878 



38 

Ftlr die Falle/ in denen Entscheidungen getroffen werden mtis- 
sen, die in Datenpfade imgesetzt werden, wird eine spezielle 
Lpgik integriert. 

5 FUr die 1. Phase des Verfahrens ziir Hardware-Blbck-Struktu- 
irierung ergibt ;sich nach alledem die in Fig.: 4 gezeigte 
Realisierung. . . 

Fiir alle Befehle mit Ausnahme der bedingten Movep-Instruktio- 

10 nen wird pro arithmetischer Einheit AU bzw. pro . Vergleiehs- 
Einheit CU eine Zahlerinstanz nach Art des vorstehend erlau- 
terten Zahlers des ersten Typs benotigt. Ein solcher Zahler 
genugt, da nur ein einfaches Belegt-Signal benotigt wird. Die 
Movep-AnweisiHigen hingegen benotigen einen Zahler des zweiten 

.15 TypS/ der in zwei Bits die teilweise (bO) und die vollstan- 
dige (bl) Belegung signalisiert . Bedingte Movep-Instruktio- 
nen, die zum zweiten Mai auf das gleiche Flag ref erenzieren, 
mtissen dieses in (im Vergleich zur ersten Referenz) inver- 
tierter Form vornehmen und werden dann in der entsprechenden 

20 AU als zweite Quelle eingetragen, wahrend das erste Quell- 
register unverandert bleibt. Dieses Verfahren ist in einer 
LUT integrierbar; Referenzen auf die nicht invertierten 
Bedingungen werden durch eine No_Entry-Signalisierung ab- 
gebrochen. > ; 

25 , 

Die zweite Phase umfaBt die Bestimmung der Register, die fur 
die betreffende Operation als Daten- und/oder Signalquelle (n) 
und Daten- und/oder Signalziel zu verwenden sihd. Dies er- 
fplgt far alle drei moglichen Register in paralleler und 
30 weitgehend identischer Form. Die Codierung des jeweiligen 

Registers innerhalb der Instruktibn wird - falls das betref- 
fende Feld einen gtiltigen Eintrag enthait - durch eine Look- 
Up-Table in eine Maske ftlr den Bitstrom zusammen mit dem 
Index in den Bitstrom Umgesetzt. 

35 

Das Blockschaltbild einer Schaltung zur Bestimmung und Codie- 
rung der als Daten- und/oder Signalquelle (n) und Daten- 
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und/oder Signalziel zu verwendenden Register ist in Figur 5 
veranschaulicht; die Identif izierung, welche der Register 
tatsaQhlich. iimgesetzt werden (mlissen) , erf blgt im betrachte- 
^ ten Bei-spiel durch die Steuerleitungen Source_Reg 1, 
5 S6urce_Reg_2, und best_Reg (siehe Figiiren 4 iind 5) . 

Source- und Destinatipnregister werden unterschiedlich behan- 
delt. Im Fall eines Destihationregisters wird der Eintrag 
markiert, lam eine Zweitbelegung idehtifizieren zu konnen 

10 (Signal No_Entry) und iim ein Data Forwarding zu triggern. 
Diese Signale entf alien ftir Sourceregister . Hier wird feine 
"straight-forward"-Generierung des Bitstromeintrags durch- 
gefuhrt, wobei allerdings die Generierung des Codes im Fall 
einer Konstanten entfallt und auf die nachfolgend beschrie- 

15 bene Stufe verlagert wird. 

In der Figur 5 ist markiert, was ausschliefilich far Source- 
register und ausschliefilich ftir Destinationregister relevant 
ist: mit (*) gekennzeichnete Telle sind nur fur Destination- 
20 register bestimmt, und mit (**) gekennzeichnete Telle sind 
nur fur Sourceregister bestimmt. 

Fur eine Konstante, die innerhalb der Codierung anstelle 
eines Sourceregisters auftreten karin/ wird ein paralleler Weg 
durchgefilhrt, der die Konstante mit den Inhalten aller Kon- 
stantenregister parallel zueinander vergleicht, und - bei 
Ungleichheit - das nachstfreie Register (Zeigerverwaltung 
durch einen Zahler) mit der Konstanten belegt und dieses 
Register als Codierung zurtlckliiefert oder - bei Gleichheit - 
die Codierung des die Konstante enthaltenden Konstantenregi- 
sters als Codierung zurUckliefert . 

Die Lbok-Up-Table wird zu diesem Zweck so gestaltet, dafi sie 
bei einem posit iven Vergleich unmittelbar die Codierungs- 
35 nummer des betreffenden Registers zum Bitfeld liefert, wah- 
rend im Fall einer NichttUDereihstinmung zusatzlich die Kon- 
stante gespeichert und der Registerzahler erhoht wird. Das 
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No_Entry-Signal wird ftir den Fall einer Belegung aller Kon- 
stanten aktiv und beendet den Algorithmiis fiir einen Instruk- 
, .tipnsbloc die Ressourcen erschopf t sind. Es sollte zudem 

beachtet werdeh/ dafi die Konstantenregsiter ein Teil des 
5 (Main-)Bitstrdias sindV da sie aus vorhergehenderi Zykien be- 
reits belegt sein kbnnen und zum Ladeh des Iristruktionsblocks 
benotigt werden. 

Das Blockschaltbild einer Schaltung zur Zuordnung der Kon- 
10 : stantenregister ist in Figur 6 veranschaulicht . 

FUr Spurceregister wird das bereits laehii^faGh erwahnte Data 
Forwarding diirchgeftihrt . Anhand der Eintragung in das 
Belegtf lag des Registers, die anzeigt, dafi dieses Register in 
15 diesem Zyklus bereits Zielregister war, wird entschieden, ob 
tatsachlich das Sourceregister oder die Eintragung, die als 
Quelle fiir das Zielregister ermittelbar ist, als neue Quelle 
in den Bitstrom eingetragen wird. 

20 Das Blockschaltbild einer hierzu geeigneten Schaltung ist in 
Figur 7 dargestellt. 

Die im Figur 7 per LUT durchgef iihrte Umcodierung der neuen 
. Quelle kann entf alien, falls alle Quellen innerhalb des Netz-- . 

25 werks identisch codiert werden. Dieser Fall, der fiir ein 
vollstandiges Netzwerk angenommen werden kann, ftihrt dazu, 
daB die im temporaren Bitstrom stehende Eintragung der Quelle 
ftir das (frtlhere) Zielregister als neue Quell-Codierung ftir 
die jet zige Operation anstelle des in der Instruktion codier- 

30 ten Quellregisters eingetragen wird. Die Auswahl erfolgt in 
jedem Fall durch einen tlber das Signal Is_Data-Forwarding 
(siehe Figur 5) angesteuerten Multiplexer. 

Fuhren alle, Operationen zum Erfolg (dies ist aiihand des Auf- 
35 tretens keiner No_Entry-Signalisierung erkennbar) , wird der 
temporare Bitstrom beim Schreibtakt mit dem vorhandenen 
Hauptbitstrom ODER-verkntipf t und in diesen zurtlckgeschrieben. 
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Die Figuren 8 und 9 zeigen Blockschaltbilder zum Einschreiben 
von Konfigurationsdaten in den temporaren Bitstrom iind in deri 
Hauptbitstrom (main bitstream) . 

Wie aus der Figiir 8 ersichtlich ist, erfolgt das Einschreiben 
von Konfigurationsdaten in den temporaren Bitstrom tlber soge- 
nannte Cross-Bar-Switches. Cross-Bar-Switches sind allgemein 
bekannt und bedtirfen keiner naheren Erlauterung. Sie leiten 

10 die Konf igurationsbits (Conf ig-Bitsj an die durch den Config- 
Index definierten Stellen im temporaren Bitstrom, wobei unbe- 
legte Ausgahge des Cross-Bar-Switch mit einem vorbestimmten 
Wert (beisplelsweise "0") belegt sind. Fur die mnemonic- 
basierte Auswahl einer physikalischen Teileinheit, die Konfi- 

15 guration d^rselben und die Zuordnung der Source- und Destina- 
tionregister zu dieser ist jeweils ein eigener Cross-Bar- 
Switch gemaB Figur 8 notwendig* 

Die Umsetzung des temporaren Bitstroms in den Hauptbitstrom 
20 (die Oberlagerurig des Hauptbitstroms durch die Ausgange der 
Cross-Bar-Switches erfolgt durch ODER-Gatter OR am Eingang 
des Hauptbitstroms (siehe Figur . 9) . 

Die vorstehend beschriebeneri Komponehten laissen sich wie in. 

25 Figur 10 gezeigt zu einer Anordnung zusammenftigen, die in der 
Lage ist> aus m-bits; ksl-Bits, ks2-BitS/ kd-Bits und p-Bits 
zusammengesetzte Befehle (siehe Figuren lA bis ID) in Konfi- 
gurations-Daten zur Konf igurierung eines Hardware-Blocks 
limzusetzen und diese Daten in einen zur Konf igurierung des 

30 Hardware-Blocks verwehdbaren Bitstrom einzuschreiben. 

Abschlieftend wird die angestrebte Umsetzung (die struktur- 
prozedurale Programmierung) auch noch in mathematischer Nota- 
tion angegeben. 



35 
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Hierzu muB zunachst eine Reihe von die Darstellungen und die 
Abbildungen betreffenden Vereinijarungen getroffeh werden. Es 
seien 



10 



15 



20 



25 



I* 

■ ± 

SR 

CR 

SR* 
DR 

PR 

DR* 

RN 

RN* 

List (pp) 
Nbit 



B 



3b OCC 



PP 

PLNUM 



35 PL 



die Menge aller Instruktibhen 

die Menge aller DatenfluB-relevanteh {.fiir die 

Blockausftihrung geeigheten) instruktionen 

die Menge aller Sourceregister einschlieBlich NO- 

SOURCE-Darstellung/ ausschlieBlich der Kpnstanten- 

register 

die Menge aller Konstantenregister einschliefilich 
der Darsteilungen filr NO_CONST und IS^CONST 

SR Kj CR ■ ■ ■ ■ 

die Menge aller Destinationregister einschliefilich 
NO_DEST-Parstellung ausschlieBlich der Predicate- 
Bits 

die Menge aller Predicate-Bits einschliefilich 

NO_PRED 

DR PR 

die Menge aller Register, SR o CR DR 

die Menge aller Register einschliefilich Predicate 

BitS/ RN «^ PR 

die Menge aller moglichen Werte fiir den Bits trom B 
als 4-.Tupel (px e PP, offset < k, nbit < k, bitwert 
< 2*" - 1)/ gegeibenenfalis abhangig von pp e PP 
die Menge der moglichen Bitwerte (bei n Bit Daten- 
breite: 0 . . 2" - 1) 

die Menge von k binarwertigen Eintragen als der 
Bitstrom zur Konf iguration der Struktur 
die Menge aller Belegurigsmarkierungen {FREE, WRITE, 
READ, READ_WRITE}. 

die Menge aller physikalischen Teileinheiten 

die Menge aller eindeutigen Nummern ftir die logi- 

schen Einheiten 

die Menge aller logischen Teileinheiten in einem 
CB, bestehend aus dem 11 -Tupel {pi € I o RN*, 
plnum e PLNUM, pp e PP, occ e OCC, source € PLNUM, 
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val G Nbit, pbit € PR, List(pp), konfOffset < k, 
konfAnzahl < k, konfWert < 2^' - 1) 

5 Bei der folgehden Beschreibiing werden einige Gfundannahmen 
und Funktibnen genutzt/ die zuriac^ werden soli en. 

Die Kennung innerhalb der Komponente occ (ftir occurence) 
wurde yierwertig gewahlt, um die Zustande .'nicht belegt* 
(FREE), 'lesend belegt* (READ), 'schreibend belegt' (WRITE) 
10 und 'lesend und schreibend belegt' (READ_WRITE) kennzeichnen 
zu k5nnen. Die Kennung 'lesend belegt* wird dabei gegebenen- 
falljs niqht weiter ausgewertet, aber dennoch innerhalb der 
Beschreibung weiternefuhrt . 

15 Weiterhin wird fiir die Register aus RN angenommen, da:B fUr 
diese Teileinheiten die logische und physikalische Darstel- 
lung ubereinstiitimt. Dies bedeutet, daii im Gegensatz zu man- 
cher funktionalen Teileinheit (etwa eine kbnf igurierbare 
Addition/Subtraktionseinheit die als zwei logische Einheiten 

20 dargestellt wird, aber naturlich nur einmal belegbar ist) fiir 
Register keine Konf igurierung durchzufuhren ist, und dafi 
zwischen der Registernuininer rn e RN und der logischen Teil- 
einheitsnununer plnum € PLNUM eine injektive Abbildung 
(gleichwohl nicht bijektiv) existiert, die im folgenden mit : 

25 rn2plnuin() bezeichnet wird, Diese Annahme gilt nicht ftir 
Predicate-Bits als Zielbits. 

Unter diesen Voraussetzungen lalit sich die Umsetzung von 
Befehlen in Strukturinformationen zur Strukturierung von 
30 Hardware-BlScken wie folgt umschreiben: 

1. In der ersten Phase wird jede Instruktion einschlieBlich 
aller Operanden aus dem originalen Binarformat in eine 
Beschreibung bi = (i € I, srl e SR, crl e CR, nl g 
35 Nbit, sr2 € SR, cr2 e CR, n2 e Nbit, dr € DR, pr_source 

e PR, pr_dest e PR) iibergefiihrt • In dieser Beschreibung 
wird fUr eine Konstante die Kennung IS_CONST far crl 
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bzw. cr2 sowie der Kpnstahtenwer.t in nl/n2 eingetragen, 
wobei in diesem Fall das entsprechende Sourceregister 
die Kennung NO_SOURCE erhalt. Entsprechend wird ftir Pre 
dicate-Befehle (etwa pge . . ) f tir dr NO_DEST eingesetzt, 
wahrend pr_dest dann die Niunmer des Predicate-Bits 
*tragt..' 

Ftir Predicated Instructions (etwa movep) wird zur besse 
ren Unterscheidbarkeit nicht pr_dest; . sondern pr_source 
-auf einen , entsprechenden Wert- gesetzt. 

Eine Instruktipn mit j g I bewirkt ein Beenden der Urn- 
set zung^ 

2. In der zweiten Phase werden maximal fiinf Eintrage in bi 
in eine Konf iguration ubersetzt , Funf deshalb, da sich 
einige Kombinationen gegenseitig ausschlieflen . Hierzu 
wird ftir die einzelnen Telle unterschieden: 

Ftir Instruktionen bi-->i e I und bi-»pr_dest == NO_PRED 
(keine Predicate-Anweisung) wird das erste Element pi e. 
PL gesucht/ das dieses i abdeckt und occ == FREE auf- 
weist. 1st dies nicht auffindbar^ so wird die Umsetzung 
.. • ;beendet. ;•*-:• 

1st pi gefunden, so werden alle Elemiente aus PL mit occ 
== READ_WRITE belegt, die auf das selbe physikalische 
Element pp € PP abgebildet.sind. Die Konf iguration ftir 
pi wird in den Bitstrom B mit Hilfe der im Tupel vorhan- 
denen Infoxiaationen eingetragen/ 

1st bi->pr_source == NO_PRED, so wird hierftir keine Ein- 
tragung durchgefahrt. Ansonsten wird nach einem p2 e 
PL mit p2->pbit == bi->pr_sburce gesucht, wobei p2->occ 
== WRITE sein muB. Ftir dieses p2 wird via List(p2->pp) 
pi geisucht und die Eintragung in den Bitstrom vorgenom- 
men, auBerdem wird p2->occ auf READ_WRITE gesetzt- 
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Ftir Instruktionen bi->i € I und bi->pr_dest != NO_PRED 
(Predicate-Ahweisung) wird das erste Element pi € PL 
gesucht/ das dieses i abdeckt und occ == FREE aufweist. 
1st dies nicht auf findbair, so wird die Umsetziihg be- 
eiidet . 

1st pi gefunden, so werden alle Elemente aus PL mit occ 
= WRITE belegt, die auf das selbe physikalische Element 
pp e PP abgebildet sind* Die Configuration ftir pi wird 
in den Bitstrom B mit Hilfe der im Tupel vorhandenen 
informationen eingetragen. 

Ftir alle Ipstruktionen i e I gilt: FUr bi-»srl und 
bi->sr2, ftir die != NO_SOURCE gilt, wird durch 
List(pl-^pp) die entsprechende Konf iguration in den 
Bitstrom B eingesetzt, falls fur die zu srl/2 gehorigen 
pH/12 G PL, pll->occ == FREE, und pl2->occ . == FREE 
gilt, zudem wird pi— >plnmn bei pll/12— >source eingetra- 
gen (fUr spateres Forwarding). 1st dies nicht der Fall, 
wird Phase 3 (Data Forwarding) durchgefiihrt . 

FUr die Sourceregister bi-->srl und bi-^sr2 wird, falls 
diese NO_SOURGE sind, in PL die entsprechenden Ein- 
trage fiir die zugehorigen p31 und p32 e PL (erhaltlich 
Qbef die angegebene Funktion rn2plnum()) p31— >occ und 
p32-^occ auf READ gesetzt, falls diese vorher != WRITE 
und != READ_WRITE waren, ansonsten auf READ_WRITE. 

Fiir die Konstantenregister cr! und cr2 wird, falls diese 
!= Np_CONST sind, zunachst fUr alle p3 e PL geprUft, ob 
p3-->pp e CR, p3->occ == READ_WRITE, und p3->val == 
bi-^nl/2 gilt. 1st dies der Fall, wird die Eintragung 
ftir p3 entsprechend dem Verfahren fUr ein Sourceregister 
durchgefiihrt . 
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FUhrt diese Suche nicht z\m Erfo.lg, mufi ein p3 e PL ge- 
sucht werden, ftlr das p4--»pp e CR und p4->occ == FREE 
gilt. 1st dies gefunden, wird bi->nl/2 in p4-^val ein- 
getragien und p4-^occ = READ_WRITE gesetzt sowie die Ein- 
tragung wie bei einem Sourceregister fortgefiihrt. I^t 
die Siiehe erfblglos, wird die Umsetzung beeridet. 

FUr das Destinationregister dr wird geprUft, ob fur den 
entspreehenden Elntrag p5 mit p5->pp dr die Bedingung 
p5->occ-== FREE Oder READ gilt. 1st dies nicht der Fall,, 
wird die Umsetzung beendet, ansonsten wird p5->occ = 
WRITE Oder READ_WRITE gesetzt und die Eintraguhg in 
List (p5-^pp) wird in den Bitstrom B tibertragen. .Fur ein 
eventuelles Data Forwarding wird pS^source = pi 
(logisches Element der wertgebenden Instruktion) einge- 
tragen. 

3. Fur alle Sourceregister sr e SR, die in Phase 2 den 

Wert fur das zugehorige Element p6 € PL den Wert p6->occ 
== WRITE Oder READ__WRITE aufweisen, wird ein Data For- 
warding durchgefiihrt, indero in den Bitstrom B nicht die 
Werte aus List (p6) , sondern aus List (p6-^source) ein- 
getragen werden. 

Durch die vorstehend beschriebene Konf igurationsdaten- 
Erzeuguhg konnen Befehle von normalen Programmen, d.h. von 
Programmen, die zur AusfUhrung in. nach dem von-Neumann- 
Prinzip arbeitenden programmgesteuerten Einheiten (her- 
kommlichen Mikroprozessoren, Mikrocontrollern etc. ) ausgelegt 
sind, in konf igurierbaren Hardware-Blocken zur AusfUhrung 
gebracht werden. 

Pie Art und Weise der Umsetzung ermoglicht es dabei, dafi 
sbwohl die Umsetzung der Befehle in die Konf igurationsdaten 
als auch die Hardware-Block-Konf igurierung unter Verwendung 
dieser Konf igurationsdaten besonders schnell, einfach und 
effizient erfolgen konnen. 
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Durch die beschriebene Umsetzung von Befehlen in Konf igura- 
tipnsdaten wird eine Fplgje . vpn Konf iguratipnsdatensatzen 
erzeugt, wqbei 

• 5 ■ • ' ' • ' ■ . ' ' ' 

- einerseits jeWeils iaSgiichst vxele Befehle in ei Kon- 
figurationdatensatz iimgesetzt werden, und 

- andererseits jeweils nur so viele Befehle in ieinen Kon- 
10 figurationsdatensatz umgesetzt werden, wie durch die zum 

Zeitpurikt der Hardware-Block- (Um-) Konf igurierung verfUg- 
baren Ressourceri des Hardware-Blocks ausftihrbar sind. 

Dadiirch kann bei einer minimalen Anzahl von Umkonf igurierun- 
15. gen des Hardware-Blocks und ohne komplizierte Und fehler- 
trachtige Uberpruf ungen vor der Verwendung der Konfigura- 
tionsdaten ein maximal effizienter Einsatz der Hardware- 
Blocke gewahrleistet werden. 

20 Dies gilt in besonderem Mafie (aber zweifellos nicht aus- 

schliefilich) , wenn ein Hardware-Block nach Art der Figur 12 
der voriiegenden Anmeldung verwendet wird und dieser durch 
die jeweiligen Konf iguratibnsdatensatze jeweils kpmplett 
vmkonf iguriert wird. 

25 • 

Ein Hardware-Block dieser Art, der unter Verwendung eine s wie 
beansprucht erzeugten Konf igurationsdatensatzes konfiguriert 
ist, fiihrt die in den betref fenden Korif igurationsdatensatz 
umgesetzten Befehle parallel aiis. Wenn der Hardware-Block die 

30 in den betref fenden Kpnf igurationsdatensatz umgesetzten 

Befehle ausgeftihrt hat, was der Hardware-Block vorzugsweise 
(beispielsweise durch das erwahnte READY-Signal oder auf 
andere Art und Weise) signalisiert, wird der Hardware-Block 
unter Verwendung des nSchsten Konf igurationsdatensatzes 

35 umkonf iguriert/ wodurch die nachsten Befehle (die zu deren 
Ausfiihrung auszuftihrenden Operationen) im Hardware-Block 
ausgefUhrt werden, Dieser nachste Konf igurationsdatensatz. 
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Tinter Verwendung dessen die Umkonfiguri e rung erfolgt, resul- 
tiert axis einer wie vorstehend iDeschrieben pder ahnlich 
durchge f Uhr ten Urns etzung der nachsten Befehle. Wenn diese 
nSchsten Befehle ausgefUhrt sind/ erfolgt erneut eine Um- 
konfiguri erung des Hardware-Blocks . Dabei wiederhoreh sich 
die erwahnteh Vorgkhgei 

Auf diese Weise kSnnen zur Ausftihrung in nach dem von- 
Neuinann-Prinzip arbeitenden programmgesteuerten Einheiten 
ausgelegte Programme schnell (insbesondere wegen der zu- 
mindest teilweisen parallelen Be fehls ausftihrung erheblich 
schneller als in herkOmmlichen programmgesteuerten Einheiten) 
und einfach in konf igurierbaren Hardware-BlOcken ausgefUhrt 
werden. 

Bei der vorstehend beschriebenen Umsetzung Befehlen in Kon- 
f igurationsdaten wird eine hyperblockweise Umsetzung, d»h. 
eine Umsetzung, bei welcher genau ein Hyperblock in eine 
Konfigurationsdaten-Einheit umgesetzt wird,. als das an- 
zustrebende Ziel angesehen. 

Noch besser ware es naturlich, wenn mehr als ein Hyperblock 
in einen Konfigurationsdatensatz umgesetzt werden konnte; 
dann konnte jeweils die maximale Anzahl von Befehlen gleich^ 
zeitig zur Ausftihrung gebracht werden- Dies ist unter be- 
stimmten UmstSnden sogar moglich. 

Insbesondere kOnnen bei Hardware-Blocken nach Art der Figur 
12 (bei Hardware-Blocken, die die vorstehend bereits erwahn- 
ten Predicate-Befehle ausftihren konnen) die Hyperblocke 0, 1 
und 2 der Sequenz 

Hyperblock_0; 
if (condition) 

HyperbloGk_l; 
else 

Hyperblock 2; 
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in einen einzigen Konf igurationsdatensatz umgesetzt warden, 
pies wird durch die vorstehend bereits erwahnte if-Konversion 
moglich. Dabei kann die Bedingung (condition) in ein p-Flag 
ximgeisetzt werden, und die Ausfilhriang der abhSngig von dieser 
Bedingung auszuftihrenden Befehle vorii Wert des p-Flag abhangig 
gemacht werden. Dabei kann beispielsweise . vorgesehen werden, 
dafi die im if-Zweig (Hyperblock_l). enthaltenen Befehle aus- 
gefUhrt werden, wenn das p-Flag den Wert. 1 hat, und dafi die 
im else Zweig (Hyperblock_2) enthaltenen Befehle ausgeftihrt 
wiarden, wenn das inverse p-Flag den Wert 1. hat. Aus. den 3 . 
Hyperblocken 0, 1 und 2 kann so ein diese umfassender Pseudo- 
Hyperblock gebildet werden, der in einen einzigen Konf igura- 
tionsdatensatz lunsetzbar ist. 

Ein solcher Pseudo-Hyperblock kann seinerseits wiederum einen 
Oder mehrere Pseudo-Hyperblocke enthalten. Ein Beispiel hier- 
ftir ist die Sequenz 

Hyperblock_0; 
if (condition) 

Pseudo-Hyperblock_l ; 
else 

PseudoTHiperblock_2 ; 

In diesein Fall kann ein Pseudo-Hyperblock gebildet werden, 
der den. Hyperblock 0 und die Pseudo-HyperblOcke 1 und 2 
umfafit. 

Bei der Uinsetzung von Befehlen in Konf igurationsdaten wird 
daher nach MOglichkeit in einem erst en Schritt versucht, 
Pseudo-Hyperblocke zu bilden. Hierzu ist es erforderlich, die 
Programinstruktur danach zu untersuchen, ob sich Pseudd- 
Hyperbiecke bilden . lassen, und bei den zur Bildung von 
Pseudo-Hyperblocken in Frage. kbmmenden Programmteilen eine 
if-Konyersion durchzuf Uhren ^ 
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In bestimmten Fallen^ insbesondere wenn durch einen kon- 
figurierbaren Hardware-Block "nur" eine bestinimte Schaltung 
(beispielsweise eine serielle Schnittstelle) realisiert 
werden soli, kann es sich als vorteilhaft erweisen, wenn der 
5 Hardware-Block unter Verwendung einer in eiher Schaltiihgs- 
beschreibtirigssprache wie beispielswe^ 

Schaltiingsdefinition konfiguriert wird, Hierzu definiert man 
die Schaltung/ die man durch den Hardware-Block realisiert 
hab.en mGchte, zunSchst in einer Schaltungsbeschreibungs- 

10 sprache und setzt dann den dabei erhaltenen Code in die 

Korifigurationsdaten (in den Kof igurationsdatensatz oder die 
Konfigurationsdatensatzfblge) urn, unter Verwendung welcher 
der Hardware-Block konfiguriert werdeh inufi/ damit dieser der 
durch ihn zu realisierenden Schaltung entspricht. Der Hard- 

15 ware-Block ist dabei vorzugsweise so aufgebaut, daB durch ihn 
je nach Konfiguration verschiedene Schaltungen realisiert 
warden konnen und/oder daB auch wie vorstehend beschrieben in 
Konf igurationsdaten umgesetzte Befehle in ihm zur Ausftihrung 
gebracht werden konnen. 

20 

- Die vorstehenden Darstellungen und Realisierungsmoglichkeiten 
bezogen sich jeweils auf einen Hardware-Block der in der Fi- 
gur 12 gezeigten Art.; Es durf te einleuchten, daB hierauf 
keine Einschrankung besteht. Die beschriebene Konf igurations- 

25 daten-Generierung laBt sich auch fUr modifizierte oder er- 
weiterte Hardware-Blocke durchfUhren. Dabei sind sowohl die 
Konf igurationsdaten-Erzeugiang als auch die Konf igurierung des 
Hardware-Blocks unter Verwendung dieser Konf igurationsdaten, 
schnell, einfach und effizient durchf Qhrbar , Nichtsdestotrotz 

30 werden dabei die Komponenten des Hardware-Blocks optimal 

ausgenutzt. Dies alles ermSglicht einen auBerst effizienten 
Betrieb des Hardware-Blocks. 



wo 00/17771 



PCT/DE99/02878 



51 



Bezugszeichenliste 



1 
2 
3 
4 
5 
6 



predecode unit 
instruction buffer 
decode, rename & load iinit 
s-unit 
data cache 
memory interface 



10 



.41 
42 
43 
44 



programmable structure buffer 
functional unit with programmable structure 
integer/address instruction buffer 
integer register file 



15 



20 



AUx arithmetische Einheit 

CU Vergleichs-Einheit 

DEMUX Demultiplexer 

MUXAx Multiplexer des ersten Typs 

MUXB Multiplexer des zweiten Typs 
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Patentahsprtiche 

1. Verfahren zum Konf igurieren eines kbnfigurierbaren Hard- 
ware-Blocks, 

d a id u r c h g . e k e n n z e i c h n e t / 
dafi die HardwaLrerBlock-^Konf igurierung unter Verwendung von 
Konfigurationsdaten erfolgt, die aus einer Umsetzung vori 
Befehlen oder Befehlsfolgen eines auszuftlhrenden Programmes 
resultieren, und dafl bei der Umsetzung der Befehle oder 
..Befehlsfolgen die Schrltte 

- Ermittlung der zur Ausfiihrung eines jeweiligen Befehls be- 
notigten Art von Teileinheit (AUx, CU/ DEMUX, MUXAx, kuXB)^ 
des konf igurierbaren Hardware-Blocks, 

- Auswahl einer noch nicht anderweitig belegten Teileinheit 
der zuvor ermittelten Art, und - sofern eine solche Teil- 
einheit gefunden werden konnte - 

- Konf igurieren von um die ausgewahlte Teileinheit. herum vor- 
gesehenen konf igurierbaren Verbindungen 

ausgeftihrt werden. 

2. Verfahren nach Anspruch 1, 

d a d u r c h g e k e n n z e i c h n e t, 

dafi die Umsietzung mit dem ersten Befehl eines nur einen Ein- 
trittspunkt und einen Austrittspunkt auf weisenden Bef ehls- 
Blocks begonnen wird. 

3. Verfahren nach Anspruch 1 oder 2, 

d a d u r c h g e k e n n z e i c h n e t, 

dafi die Umsetzung nach dem Umsetzen des letzten Befehls eines 
hur einen Eintirittspunkt und einen Austrittspunkt auf weisen- 
den Befehls-Blocks automatisch beendet Wird. 

4. Verfahren nach Anspruch 2 oder 3, 
dadurch gekennzeichnet, 
dafi die Umsetzung hyperblock-weise erfolgt. 
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5* . Verfahren nach einem der vorhergehenderi Ansprtlche, 
dadurch gekennzeichnet, 

daB die Umsetzung automatisch beendet wird, werin eine zur Um- 
setzung benotigte Komponente des Hardware-Blocks nicht Oder 
5 nicht mehr yerftigbar ist. 

6. Verfahren nach einem der vorhergehenden Ansprtlche, 
dadurch gekennzeichnet, 
daB fuhktionsmaBig konfigurierbaren Teileinheiten (AUx, C\3, 
10 DiEMUX, MUXAx, MTO des Hardware-Blocks virtuelle Einheiten 
zugeordnet werden, wobei die virtuellen Einheiten Funktionen 
reprSsentieren/ welche der betreffenden Teileinheit durch 
. unterschiedliche Konfigurationen verliehen werdeh konnen. 

#' ■ . - 

15 7, Verfahren nach Anspruch 6, 

dadurch gekennzeichnet, 

daB die virtuellen Einheiten samtlicher physikalischer Teil- 
einheiten (AUx, CU, DEMUX, MUXAx, MUXB) in einer Tabelle oder 
Liste eingetragen sind. 

20 

8. Verfahren nach Anspruch 7, 
dadurch gekennzeichnet, 

daB die Tabellen- oder Listeneintrage Inf ormationen dartiber 
enthalten, welcher physikalischen Teileinheit (AUx, CU, 
25 DEMUX, MUXAx, MUXB) die betreffende virtuelle Einheit zu- 
geordnet ist • 

9. Verfahren nach Anspruch. 7 oder 8, 
dadurch gekennzeichnet, 

30 daB die Tabellen- oder Listeneintrage informationen daruber 
enthalten, wie die ziigeordnete physikalischen Teileinheit 
(AUx, CU, DEMUX, MUXAx, MUXB) zu konf igurieren ist, uia ihr 
die durch die virtuelle Einheit reprasentierte Funktion zu 
verleihen. 

35 

10. Verfahren nach einem der vorhergehenden AnsprUche, 
dadurch gekennzeichnet, 
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daB die Auswahl einer zur AusfUhrung eines Befehls benotigten 
Teileinheit (AUx, CU, DEMUX/ MUXAx, MtJXB) tiber ^ihe Suche 
nach einer virtuellen Einheit der benotigten Art erfolgt. 

5 11.' Verfahreri nach Anspruch 10/ 

d a. d u r c h g e k e h ri .2 e i c h n e t/ 
dafl daftlr gesorgt wird, daB die zur Verwendung ausgewahlte 
virtuelle Einheit der benotigten Art und diejenigen virtuel- 
len Einheiten/ die der selben physikalischen Teileinheit 
10 (AUx, CU/ DEMUX, MU5CAX/ MUXB) zugebrdnet sind wie die ausr . 
gewahlte virtuelle Einheit/ bei nachf olgenden Umsetzungen 
hicht mehr zur Verwendung ausgewahlt werden konnen; 

12. Verfahren nach einem der vorhergehenden Anspruche, 

15 dadurch gekennzeichnet/ 

dafi.beim Konf igurieren der um die ausgewahlte Teileinheit 
(AUX/ CU, DEMUX/ MUXAX/ MUXB) herum vorgesehenen konfigurier- 
baren Verbindungen zur Verbindung der betreffenden Teilein- 
heit mit einer durch den umzusetzenden Befehl definierten 

20 Daten- und/oder Signalquelle iiberprilft wird, ob die betref- 
fende Daten- und/bder Signalquelle ein Speicherbereich ist, 
der zuvor durch eine der Teileinheiten des Hardware-Blocks 
beschrieben wurde. 

25 13. Verfahren nach Anspruch 12, 

dadurch gekennzeichnet/ 

daB dann/ wenn f estgestellt wird/ daB die durch den umzuset- 
zenden Befehl definierte Daten- und/oder Signalquelle zuvor 
durch eine der Teileinheiten (AUx, CU/ DEMUX/ MUXAx, MUXB) 
30 des Hardware-Blocks beschrieben wurde, diese Teileinheit als 
Daten^ und/oder Signalquelle verwendet wird. 

14. Verfahren nach einem der vorhergehenden Ansprliche, 
dadurch gekennzeichnet/ 
35 daB beim Konf igurieren der um die ausgewahlte Teileinheit 

(AUX/ CU/ DEMUX, MUXAX/ MUXB) herum vorgesehenen konfigurier- 
baren Verbindungen zur Verbindung der betreffenden Teil- 
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einheit mit einem durch den umzusetzenden Befehl definierten 
Daten- und/oder Signalziel tiberprtift wird, ob das betref fende 
Daten- und/oder Signalziel ein Speicherbereich ist, der auch 
durch eine andere Teileinheit des Hardware-Blocks beschrieben. 
5 wird. 

15. Verfahren nach Anspruch 14, 

d a d u r c h g e k e n n z e i c h n e t, 

daii dann, wenn f estgestellt wird, dali das diirch den umzuset- 
10 zenden Befehl -definierte Daten- und/bder Signalziel ein 

Speicherbereich iist, dex auch durch eine andere Teileinheit 
(AUx,/ CU, DEMUX/ MUXA?;, MUXB) des Hardware-Blocks begchrieben 
wird, ein anderer Speicherbereich als Daten- und/oder Signal- 
ziel verwendet wird. 

15 

16. Verfahren nach Anspruch 15, 

d a d u r c h g e k e n n z e i c h n e t , 

dali fiir die das selbe Daten- und/oder Signalziel reprasentie- 
renden Speicherbereiche das bei superskalaren Prozessoren an- 
20 gewandte register renaming durchgeftihrt wird. 

17. Verfahren nach einem der vorhergehenden Ansprtiche, 
d a d u r c h g e k e n n z e i c h n e t, 

daB dann, wenn imiMzusetzenden Befehl eine Konstante enthal^ 
25 ten ist, nach einem die Konstante enthaltenden Konstanten- 

Speicherbereich gesucht wird und dann, wenn ein solcher Kon^ 
stanten-Speicherbereich gefunden wurde, dieser Konstanten- 
Speicherbereich als Daten- und/oder Signalquelle verwendet 
wird. 

30 

18. Verfahren nach Anspruch 17, 
dadurch gekennzeichnet, 

daB dann, wenn die Konstante nicht bereits in einem der vor- 
handenen Konstanten-Speicherbereiche gespeichert ist, die 
35 Konstante in einen neuen Konstanten-Speicherbereich gespei- 
chert wird, und dieser neue Konstanten-Speicherbereich als 
Daten- und/oder Signalquelle verwendet wird. 
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19. Verfahren insbesondere nach eineia der vorhergehenden 
Arispriiche/ 

dadurch gekennzeichne t, 
5 daB bei der Umsetzung vori Befehleh in Konf igurationsdaten 
versucht wird/ ihehrere Hyperblb 
Hyperblocke zu bilden. 

20. Verfahren nach Anspruchi 19, 
10 dadurch g e k e n n z e i c h n e t, 

daB die Pseudo-Hyperblock^ unter Verwendung der if-Konversion 
gebildet werden. '\[ 

21. Verfahren nach Anspruch 19 oder 20, 

15 dadurch gekennzeichne t, 

daB die Umsetzung von Befehlen in Konf igurationsdaten nach 
Moglichkeit pseudo-hyperblock-weise erfolgt. 

22. Verfahren zum Konf igurieren eines konf igurierbaren Hard-- 
20 ware-Blocks, 

dadurch gekennzeichne t, 
daB die Hardware-Block-Konf igurierung unter Verwendung von 
Konf igurationsdaten erfolgt, die aus einer Umsetzung des 
Codes resultieren, der getneriett wird,. wenn eine Schaltung, 
25 die durch den konf igurierbaren Hardware-Block realisiert 

werden soli, unter Verwendung einer Schaltungsbeschreibungs- 
sprache definiert wird. 

23. Verfahren nach Anspruch 22, 

30 dadurch gekennzeichnet, 

daB VHDL als Schaltungsbeschreinbungssprache verwendet wird. 
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(57) Abstract 



The invention relates to various methods for configiiring configurable hardware blocks. The methods arc especially characterized by 
generation of the configuration data u.sed to configure the haniware blocks. The methods described for generating configuration data enable 
configuration daita to be generated and allow hardware blocks to be configured easily, quickly and efficiently using said configuration data. 



(57) Zusammenfassung 

Cs werden verschiedene Verfahrcn zur Konfiguriening von kpnfigurierbarcn Hardware-Blocken beschrieben. Die Vcrfahren zcichncn 
sich insbcsondere durch die Genericrung der Kohfigurationsdaten aus, unter Venvendung welcher die Hardware-B16cke korifiguriert 
wenlen. Durch die bcschricbcne Konfigurationsdatciv-Erzcugung k6nncn sowohl die Konfigurationsdaten-Erzeugung selbst als auch die 
Hanlwarc-Block-Konfigiirierung unter Vcrwendung dteser Konfigurationsdatcn einfach, schnell und eflizient durchgeffthrt werden. 
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